Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!transit3.readnews.com!news-out.readnews.com!transit4.readnews.com!panix!not-for-mail From: Grant Edwards Newsgroups: comp.lang.python Subject: Re: Pass data to a subprocess Date: Wed, 1 Aug 2012 19:48:16 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 41 Message-ID: References: <5017EFB0.6080608@shopzeus.com> NNTP-Posting-Host: dsl.comtrol.com X-Trace: reader1.panix.com 1343850496 10283 64.122.56.22 (1 Aug 2012 19:48:16 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 1 Aug 2012 19:48:16 +0000 (UTC) User-Agent: slrn/pre1.0.0-18 (Linux) Xref: csiph.com comp.lang.python:26378 On 2012-08-01, Laszlo Nagy 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??