"Kim Barrett" wrote:
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.)
What the present library implementation is trying to do with this reference count mechanism is to emulate the Windows behavior on POSIX systems. 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.
The API may provide function destroy_old_shmem_and_create_new_one(). With enough of access rights and proper lifetime management (necessary for this kind of applications anyway) this should solve both development phase and crashing clients.
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
Second question: Why use different implementations on different platforms? Why not use the (admittedly somewhat clumsy to use directly) SysV shared memory API, which is pretty widely supported?
1. Latest Windows do not support POSIX interface, unless I misread something. 2. Win32 security needs to be taken into account for this library and this requires native API. /Pavel