[issue29303] asyncio.Lock.acquire() does not always yield

2017-01-17 Thread Guido van Rossum
Guido van Rossum added the comment: No, `yield from` (or, in Python 3.5+, `await`) is not meant to bound back to the scheduler. If the target is a coroutine that itself doesn't yield, it is a *feature* that the scheduler is bypassed. If you want to force a trip through the scheduler, use

[issue29303] asyncio.Lock.acquire() does not always yield

2017-01-17 Thread anonymous2017
anonymous2017 added the comment: I may have mis-characterized the original report. Rephrasing just to make sure it is correctly addressed: First, it is not about fairness. Sorry for the original characterization. I was trying to understand what was happening. Second, the precise issue is

[issue29303] asyncio.Lock.acquire() does not always yield

2017-01-17 Thread Guido van Rossum
Guido van Rossum added the comment: Locks are not meant to have predictable behavior like that. They are meant to protect against concurrent access. If you want fairness you have to look elsewhere. -- ___ Python tracker

[issue29303] asyncio.Lock.acquire() does not always yield

2017-01-17 Thread anonymous2017
New submission from anonymous2017: Details here: http://stackoverflow.com/questions/41708609/unfair-scheduling-bad-lock-optimization-in-asyncio-event-loop Essentially there should be a `yield` before this line otherwise a coroutine that only acquires and releases a lock will never yield to