[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles

[Adam Meily]

Adam Meily added the comment:

@r.david.murray: Yes I could make a test.

@haypo:

I did not know about the PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure, thanks for the heads up. You pointed me in the right direction, and I see now that you've been following this, and similar, subprocessing issues on Windows for some time.

I understand the hesitancy for adding a Lock to the standard library. Unless I am mistaken, I don't think my patch could cause a deadlock. I am releasing the lock in a `finally` block. So, the way I see it, the only way a deadlock can occur is if the thread crashes while in C code, which will cause the `finally` block to not execute. The lock will stay acquired, and then another thread will deadlock trying to acquire the lock. However, if that is the case and the thread crashed in C, the whole interpreter instance would have crashed, not just the Thread, which would make the deadlock impossible.

It looks like the structure you reference to, PROC_THREAD_ATTRIBUTE_HANDLE_LIST (STARTUPINFOEX), is only available in Windows Vista and after. Which means that Windows XP/Server 2003 would still have this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24909>
_______________________________________