STINNER Victor added the comment: Yeah, when stdin, stdout or stderr is a pipe, subprocess.Popen() calls CreateProcess() with the STARTF_USESTDHANDLES flag and bInheritHandles=TRUE.
This issue was fixed on UNIX for file descriptor inheritance. The fix is a major change: Python 3.4 now only creates non-inheritable file descriptors by default. See the PEP 446, especially the "Only Inherit Some Handles on Windows" section: https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows This part is out of the scope of the PEP. For me, the real fix would be to create non-inheritable I guess that this issue is a duplicate of the issue #19575. I'm again the idea of adding a lock inside the subprocess module. I may add deadlocks. You can already put this lock in your application, before calling subprocess.Popen (directly or indirectly). > Currently, the Popen constructor will duplicate any stdout, stdin, and/or > stderr handle passed in and make them inheritable, by calling > DuplicateHandle. If two threads call Popen at the same time, the newly > created inheritable handles will leak into the subprocess that's running > being created in the opposite thread. This has consequences when two or more > subprocesses are piped together and executed at the time time. This is a race condition specific to the subprocess module. Usually, handles are created non-inhertable, so calling CreateProcess() with bInheritHandles=TRUE is not an issue. The real fix is *not* make duplicated handles inheritable, but use the new PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure. Again, see the issue #19575. ---------- nosy: +haypo _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24909> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
