On 2012-08-01, Laszlo Nagy <gand...@shopzeus.com> wrote:
>
>>>> things get more tricky, because I can't use queues and pipes to
>>>> communicate with a running process that it's noit my child, correct?
>>>>
>>> Yes, I think that is correct.
>> I don't understand why detaching a child process on Linux/Unix would
>> make IPC stop working. Can somebody explain?
>
> It is implemented with shared memory. I think (although I'm not 100%
> sure) that shared memory is created *and freed up* (shm_unlink() system
> call) by the parent process. It makes sense, because the child processes
> will surely die with the parent. If you detach a child process, then it
> won't be killed with its original parent. But the shared memory will be
> freed by the original parent process anyway. I suspect that the child
> that has mapped that shared memory segment will try to access a freed up
> resource, do a segfault or something similar.
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.
--
Grant Edwards grant.b.edwards Yow! Why is it that when
at you DIE, you can't take
gmail.com your HOME ENTERTAINMENT
CENTER with you??
--
http://mail.python.org/mailman/listinfo/python-list
