Łukasz Langa <[email protected]> added the comment:
Andrew is right because a Condition *is* a lock. The confusing thing about
this construct is that the actual logic "condition" that we're waiting for is
external.
It can be controlled by another coroutine that will just let us know by calling
`cond.notify()` when the condition is met. On the receiver side it looks like
this:
async with cond: # in this block you hold the lock
await cond.wait() # (this temporarily releases the lock as long as it
waits)
print("Another coroutine called .notify(). I hold the lock now!")
It can also be used like Andrew demonstrated above, where *we* run the logic
"condition" check ourselves and that check *also* requires a lock to be correct:
async with cond: # in this block you hold the
lock
while not condition_check_with_lock(): # <- this is the actual
"condition" check
await cond.wait() # (temporarily releases the
lock while it waits)
print("Check passed and I'm holding the lock now!")
Personally I find the latter example confusing because it doesn't require
another coroutine to ever `.notify()` us if the initial
`condition_check_with_lock()` returned True, but it *does* require another
coroutine to `.notify()` us if that initial check returned False.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue33546>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
