James Mansion 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.
That would be incredibly slow. We would need to maintain a per-process DB for name-mapping for each use. I think it's prohibitively expensive when comparing to a few atomic operations.
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.
Which interface do you consider adequate for portability?
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?
Of course. Everything you map in a file ends in the file, if you write a wrong data, it's your problem. This might unacceptable for some, but it has some pretty good uses. For named resources (sem_open...) Unix resources have kernel lifetime and they need to be unlinked, just like files. This has some good uses cases but also problems and I'm open to suggestions. Achieving windows lifetime (reference counted) semantics is really impossible in the presence (unless you develop a server ipc process like wine) of process crashes is and that was a widespread complain in the pre-accepted Interprocess library. Best, Ion