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.