[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2020-11-14 Thread Charles-François Natali
Change by Charles-François Natali : -- nosy: -neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2020-11-08 Thread Irit Katriel
Change by Irit Katriel : -- versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.6, Python 2.7, Python 3.2, Python 3.3 ___ Python tracker ___

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2012-04-25 Thread Sye van der Veen
Sye van der Veen syeber...@gmail.com added the comment: This issue _does_ exist on Windows, and is not limited to the case where the master process exits before its children. The following code, which is almost exactly that from the 2.7.3 documentation, deadlocks on Win7 (Py3.2 and 2.7) and

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Luke
New submission from Luke lcamp...@email.unc.edu: I have found that when using multiprocessing.Connection objects to pass data between two processes, closing one end of the pipe is not properly communicated to the other end. My expectation was that when calling recv() on the remote end, it

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: That's because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()). Just add p1.close() at the beginning of fn() and you'll get EOF. Closing as invalid. -- nosy: +neologix resolution: -

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Luke
Luke lcamp...@email.unc.edu added the comment: That's interesting, thanks for your response. It is also a bit awkward.. Might I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn't using (especially since it

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Well, in this regard it behaves like a Unix pipe/socket (in the duplex case it's implemented with a Unix domain socket), so I find it quite natural (of course, you have to know about FD inheritance upon fork()). I'm not convinced it's

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Antoine Pitrou
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file22569/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12488 ___

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr added the comment: Well, I think it deserves a comment in the documentation that behaviour of Pipes and Queues when one of the process terminates is undefined and implementation-dependent. By the way, there's internal support in 3.3 to reliably detect killed

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Alright. Luke, if you're motivated, feel free to provide a patch. The relevant file is Doc/library/multiprocessing.rst. -- ___ Python tracker rep...@bugs.python.org

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

2011-07-04 Thread Antoine Pitrou
Antoine Pitrou pit...@free.fr added the comment: By the way, if you don't want children processes to continue running when the master exits, just make them daemonic processes (by adding daemon=True to the Process() constructor call). -- ___ Python