I still don't get it. shm_unlink() works the same way unlink() does.
The resource itself doesn't cease to exist until all open file handles
are closed. From the shm_unlink() man page on Linux:
The operation of shm_unlink() is analogous to unlink(2): it
removes a shared memory object name, and, once all processes
have unmapped the object, de-allocates and destroys the
contents of the associated memory region. After a successful
shm_unlink(), attempts to shm_open() an object with the same
name will fail (unless O_CREAT was specified, in which case a
new, distinct object is created).
Even if the parent calls shm_unlink(), the shared-memory resource will
continue to exist (and be usable) until all processes that are holding
open file handles unmap/close them. So not only will detached
children not crash, they'll still be able to use the shared memory
objects to talk to each other.
I stand corrected. It should still be examined, what kind shared memory
is used under non-linux systems. System V on AIX? And what about
Windows? So maybe the general answer is still no. But I guess that the
OP wanted this to work on a specific system.
Dear Andrea Crotti! Please try to detach two child processes, exit from
the main process, and communicate over a multiprocessing queue. It will
possibly work. Sorry for my bad advice.
--
http://mail.python.org/mailman/listinfo/python-list