Received: by 10.180.100.98 with SMTP id ex2mr1557032wib.4.1344321763753; Mon, 06 Aug 2012 23:42:43 -0700 (PDT) MIME-Version: 1.0 Path: n2ni5647564win.0!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ctu-peer!ctu-gate!news.nctu.edu.tw!usenet.stanford.edu!panix!not-for-mail From: Grant Edwards Newsgroups: comp.lang.python Subject: Re: Pass data to a subprocess Date: Thu, 2 Aug 2012 14:29:09 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 48 Message-ID: References: <5017EFB0.6080608@shopzeus.com> NNTP-Posting-Host: dsl.comtrol.com X-Trace: reader1.panix.com 1343917749 9698 64.122.56.22 (2 Aug 2012 14:29:09 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Thu, 2 Aug 2012 14:29:09 +0000 (UTC) User-Agent: slrn/pre1.0.0-18 (Linux) Bytes: 3723 On 2012-08-02, Laszlo Nagy wrote: > >> 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. Note that when I say the detached children will still be able to talk to each other using shared memory after the parent calls shm_unlink() and exit(), I'm talking about the general case -- not specifically about the multiprocessing module. There may be something else going on with the multiprocessing module. > 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. I'm not claiming it will work, since I don't know how the IPC in the multiprocessing module works. It may indeed break when a child process is detatched (which I'm assuming means being removed from the process group and/or detached from the controlling tty). But, I'm not aware of any underlying Unix IPC mechanism that breaks when a child is detached, so I was curious about what would cause multiprocessing's IPC to break. -- Grant Edwards grant.b.edwards Yow! I didn't order any at WOO-WOO ... Maybe a YUBBA gmail.com ... But no WOO-WOO!