On Sun, Jun 21, 2009 at 3:15 PM, James Mansion<james@mansionfamily.plus.com> wrote:
Ion Gaztañaga wrote:
Because that semaphore couldn't be placed in shared memory and memory-mapped files, like its POSIX equivalent with pshared set to true:
int sem_init(sem_t *sem, int pshared, unsigned int value);
That's not strictly true. Put an unique name in shared memory, and do something to cache the handle in accessing processes or the cost *will* suck. Unfortunately just basing things on POSIX is a pretty bad design decision if you want portability - if you manage it as 'a shared thing' and handles then its easier to implement with either, though POSIX is still generally crappy because its hard to avoid races to initialise the shared thing, and because its so badly defined what you can put it in.
POSIX shared memory? SysV shared memory? Memory mapped file? memory mapped /dev/null?
For a memory mapped file, does the semaphore state persist if the file is closed by all processes? What about closed by all processes, and the system is rebooted?
Its a khazi, it really is.
Not sure what a khazi is :) But regardless, I also feel like modelling it after posix semaphores is a bit contrary to how other libraries in boost work, or how boost libraries are supposed to work in general (correct me if I'm wrong). It seems to me like you should be starting with requirements, and molding the o/s primitives to fit the requirements. Not molding the requirements to fit specific o/s primitives. For example, does anyone actually care that specifically that a semaphore is in shared memory or a memory mapped file? Or do they just care that it can be accessed from multiple processes? Ok fine, before you shoot me, I'm sure that some people actually do want it to be in a specific type of memory for whatever reason. But regardless, both o/s'es provide native support for semaphores that can be used from multiple processes. It seems like the interface should be designed simply to distinguish whether or not it can be used in multiple processes, and make the internals hide the rest. There may be situations where you really want some o/s specific behavior, but that's what an interprocess::posix namespace could be used for. Like in boost::asio I can use boost::asio::windows::overlapped_ptr