On Thu, Nov 20, 2014 at 5:37 PM, David Coles <
coles...@gmail.com> wrote:
>
> My current workaround is to roll my own condition timeout-cancellation logic, but it really seems like wait_for and Condition should be able to play nicer together.
Seems like this isn't quite sufficient by itself. There's a race
condition that can occur if the waiter task is blocked on lock
reacquisition after notification (a good example would be multiple
waiters that cause contention on the lock or just having the notifier
yield between notify and release).
If the waiter is cancelled at this time it will also cause cond.wait()
to return without the lock and cause another RuntimeError in the
future. I don't think it's possible to detect this in my
cond_wait_timeout since cond.locked() may be True because of another
task
Something like this in asyncio.locks would seem sufficient:
finally:
# Must reacquire lock even if wait is cancelled
while True:
try:
yield from self.acquire()
except CancelledError:
pass