Pass data to a subprocess

Wed Aug 1 15:48:16 EDT 2012

On 2012年08月01日, Laszlo Nagy <gandalf at 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??