Cancelled lock waiter wakes up the next one if any by msornay · Pull Request #467 · python/asyncio (original) (raw)
This repository was archived by the owner on Nov 23, 2017. It is now read-only.
Conversation10 Commits2 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
@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.
| @@ -71,6 +71,31 @@ def test_context_manager_with_await(self): |
|---|
| self.loop.run_until_complete(test(primitive)) |
| self.assertFalse(primitive.locked()) |
| def test_finished_waiter_cancelled(self): |
| async def create_waiter(lock, fut): |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the @coroutine decorator and generators in unittests. We'll start using 'async def' when 3.6 is out and we start working on Python 3.7.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even in test_pep492.py ? Should I move the test ?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test_pep492 is ignored on Pythons < 3.5 and it tests specifically async/await and asyncio.
Yeah, this test should be where all tests of lock/synchronization primitives are.
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.
