Closed msornay closed 6 months ago
@gvanrossum @asvetlov I'm not sure I can review this (I never touched/used that code). Can you take a look if you have time and you are familiar with the code?
Sorry, I can't do it this week or next.
Looks like this PR is doing a right thing. @msornay please update the tests, and I will merge it.
Hello, and thanks for your contribution!
Unfortunately we couldn't find an account corresponding to your GitHub username at bugs.python.org (b.p.o). If you don't already have an account at b.p.o, please create one and make sure to add your GitHub username. If you do already have an account at b.p.o then please go there and under "Your Details" add your GitHub username.
And in case you haven't already, please make sure to sign the PSF contributor agreement (CLA); we can't legally look at your contribution until you have signed the CLA.
Once you have done everything that's needed, please reply here and someone will verify everything is in order.
Everything should be in order.
After applying patch #363 and #467 to Python 3.5.2, the dead-lock did indeed no longer occur, but the opposite did; Sometimes on releasing the lock, a RuntimeError exception is raised telling me the lock was not acquired.
lock.acquire() try: ... do stuff ... finally: lock.release() # RuntimeError occured here
So far, I did not manage to create a simple test case, and I know this does not help much without it, but should someone experience this same behavior, then just know you are not the only one.
Please reopen this PR at https://github.com/python/cpython. This repo is going to be deleted soon.
Fixes http://bugs.python.org/issue27585
Without the fix the unit test deadlock, I haven't managed to make it fail (using wait_for() seems to avoid the deadlock)