[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

STINNER Victor added the comment: > Oh by the way, this issue was fixed on UNIX in Python 3.2: all file > descriptors are now closed by default (close_fds=True by default on UNIX). Issue fixed in Python 3.4 (sorry, 3.4, not 3.2): https://www.python.org/dev/peps/pep-0446/ -- resoluti

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

Irit Katriel added the comment: I will close this as out of date unless someone objects. -- nosy: +iritkatriel status: open -> pending ___ Python tracker ___ _

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

Geoffrey Bache added the comment: Thanks Victor, yes I already created my own lock which fixed the issue for me. Maybe it would be worth adding a note to the documentation about this in the meantime (especially for Python 2)? -- ___ Python tracker

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

STINNER Victor added the comment: Oh by the way, this issue was fixed on UNIX in Python 3.2: all file descriptors are now closed by default (close_fds=True by default on UNIX). -- ___ Python tracker __

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

STINNER Victor added the comment: The PEP 446 partially fixes this issue. The issue #19764 should fix it completly. Since you are using Python 2, you should not wait until the issue is fixed, but work around it. To workaround the issue: use you own lock around the creation of processes. Examp

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

Geoffrey Bache added the comment: Just ran into this on Python 2.6 also. -- versions: +Python 2.7 ___ Python tracker ___ ___ Python-bu

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

Changes by Geoffrey Bache : -- nosy: +gjb1002 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue12739] read stuck with multithreading and simultaneous subprocess.Popen

New submission from Joe Hu : When multiple threads create child processes simultaneously and redirect their stdout using subprocess.Popen, at least one thread will stuck on reading the stdout after its child process exited, until all other processes are also exited. The test case reproduces t