From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2006-03-09 19:07:52
"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
2. Win32 security needs to be taken into account for this library
and this requires native API.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk