|
Boost : |
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
something.
2. Win32 security needs to be taken into account for this library
and this requires native API.
/Pavel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk