Re: [boost] [interprocess] shared memory lifetime

From: Kim Barrett (kab_at_[hidden])
Date: 2006-03-09 22:55:14

>  From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
>  Date: Fri, 10 Mar 2006 01:07:52 +0100
>
>  "Kim Barrett" wrote:
>  > 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.

I don't think that actually helps at present.

For one thing, a Windows developer will never even notice the problem
that this proposed function is intended to address, and may well
produce a system design which is difficult to port to a POSIX platform
because of that. That would defeat some of the purpose of using this
library.

An example would be a system which used the existing create_or_open
variants. If one designed a system around those and developed it on
Windows, one would be in for a rude shock when porting to a POSIX
system. (It might be argued that the create_or_open variants are just
a bad idea because of the problem of distinguishing between a live and
a zombie shared object, but eliminating them would prevent access to
existing OS facilities.)

The problem is that, when correctly functioning, the reference
counting mechanism can actually lead one to adopt an approach to
lifetime management that simply doesn't work in the face of a broken
reference counting implementation. It might be that this can be
somewhat ameliorated through documentation, but it would still be
a potential portability trap.

>  > 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.

Yes, I think that's correct. But I think Windows *does* support the
SysV shared memory API.

>  2. Win32 security needs to be taken into account for this library
>  and this requires native API.

Security needs to be taken into account for any platform, and that's a
real weaknesses of the present library interface.