Hi Kim,
First let me make sure I understand what is going on here.
On Windows, the shmem library is presently using create_file_mapping and open_file_mapping, while on POSIX systems it is using shm_open.
Right.
An object created with create_file_mapping exists until there are no references, assuming I'm understanding what you've said. (I don't have (easy) access to Windows API documentation, so can't go look up this information. Please correct me if you see any confusion.)
You can use MSDN (www.msdn.com)
A POSIX shared memory object exists from the time it is created until it is unlinked and all references are gone (or the system is rebooted). (It becomes inaccessible to further shm_open calls if unlinked, but remains open to processes that had already opened it.)
Right. The difference is that in windows, if there's still a process connected to the shared memory, another process can open the same segment. If a UNIX process calls shm_unlink, them the processes that opened the shared memory can still work on it, but if another process can't use that memory, because the name is removed. From OpenGroup site: http://www.opengroup.org/onlinepubs/007908799/xsh/shm_unlink.html "The shm_unlink() function removes the name of the shared memory object named by the string pointed to by name. If one or more references to the shared memory object exist when the object is unlinked, the name is removed before shm_unlink() returns, but the removal of the memory object contents is postponed until all open and map references to the shared memory object have been removed." So if a process calls shm_unlink another process can create new shared memory segment with the same name, but never connect to that old shared memory. This is different from a file unlink behavior, I think.
What the present library implementation is trying to do with this reference count mechanism is to emulate the Windows behavior on POSIX systems.
Right. I find windows behaviour easier to implement with posix (when there is no crash) than emulating posix with windows.
Unfortunately, as has been noted, that emulation really isn't very reliable in the face of ill-behaved (i.e. crashing) clients. And I'm pretty sure there isn't a solution to that problem, at least not with the shm_open &etc API.
I'm sure there is a solution. But every implementation I've checked (apache for example) doesn't solve this. Last time I checked Apache portable runtime tries emulates posix-like behavior but shm_unlink in windows in empty. One option is to use a memory mapped file to emulate posix-like behavior in windows. But it surely will be slower (the OS will dump data to file) and the unlink is not trivial.
First question: Why not use the shm_open interface on Windows? One possible answer would be that the Windows POSIX support doesn't include the shm_xxx API. And that might even be the answer, since some web searches have led me to suspect that Windows only supports the SysV shared memory API. Which leads to
Windows natively does not support posix nor System V. I think that with Unix Services for Windows (previously Interix)you have system V interface. I think Unix Services for Unix is a free download now, but I think you need to use that environment to build a Unix-like application (using gcc compiler). I don't know if those system V functions are available with a normal windows environment.
Of course, we have yet to have the discussion of which behavior is actually preferable. But it is certainly the case that the present situation, where the behavior is not documented and is buggy on non-Windows platforms, is not ideal.
I'm not happy with the behavior of the shared memory. For a not reference-counted implementation you can use memory mapped files. I don't know if this will be slower, though. Ion