[SciPy-user] shared memory machines
Fri Feb 6 09:54:42 CST 2009
On Feb 6, 2009, at 10:38 AM, Sturla Molden wrote:
> On 2/6/2009 4:26 PM, Philip Semanchuk wrote:
>> You are correct that posix_ipc doesn't close handles when
>> THis is a deliberate choice -- the documentation says that closing
>> handle makes the IPC object no longer available to the *process*. So
>> if one has multiple handles to an IPC object (say, inside multiple
>> threads), closing one would invalidate them all. But as I write this,
>> I'm wondering if that's not just a documentation bug and something
>> with which I ought to experiment.
> I have been thinking about this as well. I am mostly familiar with
> Windows so excuse my terminology: We don't want an array to call
> CloseHandle() on a mapped segment that another array is still using.
> effect would be global to the process. Thus, we would either need to
> maintain some sort of global reference count for all mapped shared
> resources, or make duplicates of the handle. On Windows there is a
> function called DuplicateHandle() that will do this. I am not sure
On Unix, one can duplicate a file handle with a call to dup().
Note that the doc for shm_unlink() says this:
"If one or more references to the shared memory object exist when the
object is unlinked, the name shall be removed before shm_unlink()
returns, but the removal of the memory object contents shall be
postponed until all open and map references to the shared memory
object have been removed."
Furthermore (and this is where it gets tricky):
"Even if the object continues to exist after the last shm_unlink(),
reuse of the name shall subsequently cause shm_open() to behave as if
no shared memory object of this name exists (that is, shm_open() will
fail if O_CREAT is not set, or will create a new shared memory object
if O_CREAT is set)."
You'd have to do your testing very carefully to see if dup() really
increments the kernel's reference count on a shared memory segment.
More information about the SciPy-user