From: "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> 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.