David Coles added the comment:
This issue can still be reproduced on Python 3.5.0a1.
(Triggers a "RuntimeError: Lock is not acquired" on cond.release())
Please let me know if there's any further steps you'd like me to take here.
--
versions: +Python 3.5
David Coles added the comment:
Just for context, the reason for using a custom wait function
(cond_wait_timeout) rather than the more idiomatic
asyncio.wait_for(cond.wait(), timeout) is that the combination introduces
another subtle, but nasty locking inconsistency (see
https://groups.google.
David Coles added the comment:
Hi Victor,
(Sorry for the delay, I think GMail ate the notification)
The main issue is that Condition.wait MUST reacquire the associated lock
released on entry to wait() before returning or else the caller's assumption
that it holds a lock (such as `with lock:`)
STINNER Victor added the comment:
threading.Condition.wait() implementation is very similar to
asyncio.Condition.wait(), and the threading code only call acquire() once, it
doesn't loop or ignore exceptions.
Does it mean that threading.Condition.wait() has the same issue?
--
STINNER Victor added the comment:
I don't like the idea of ignoring exceptions (CancelledError). An option may be
to store the latest exception and reraise it when the condition is acquired.
I'm not sure that it's safe or correct to "retry" to acquire the condition.
I don't know what I should
New submission from David Coles:
If a task that is waiting on an asyncio.Condition is cancelled after
notification but before having successfully reacquired the associated lock, the
acquire() will be cancelled causing wait() to return without the lock held
(violating wait()'s contract and leav
