This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author meilyadam
Recipients gregory.p.smith, meilyadam, paul.moore, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Date 2015-08-21.18:31:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1440181911.67.0.240494405492.issue24909@psf.upfronthosting.co.za>
In-reply-to
Content
@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.
History
Date User Action Args
2015-08-21 18:31:51meilyadamsetrecipients: + meilyadam, gregory.p.smith, paul.moore, vstinner, tim.golden, r.david.murray, zach.ware, steve.dower
2015-08-21 18:31:51meilyadamsetmessageid: <1440181911.67.0.240494405492.issue24909@psf.upfronthosting.co.za>
2015-08-21 18:31:51meilyadamlinkissue24909 messages
2015-08-21 18:31:49meilyadamcreate