Well, at that point all three coroutines are blocked in wait(), and
(per condition variable specs) wait() releases the lock. I haven't
looked at Trollius so I don't know what it is doing -- maybe it
requires more ticks to reach this state?
FWIW, the idiom "yield from <lock>" is meant to be only used in
combination with a with-statement, like this:
with (yield from lock):
<code running with the lock held>
This is meant to be the closest analog to
with lock:
<etc.>
when using threaded locks. It is different from
yield from lock.acquire()
which matches the threaded
lock.acquire()
(i.e. no automatic release at end of block).
The problem is that the current lock implementation in asyncio allows
incorrect uses to go unchecked. I wonder if the correct solution isn't
to define an explicit context manager, so that "with lock" will fail
(no __enter__ method) rather than silently entering the block without
acquiring the lock.
I've just filed http://code.google.com/p/tulip/issues/detail?id=100 to
track this.
On Tue, Jan 7, 2014 at 11:48 AM, Marc Schlaich <[email protected]> wrote:
> Guido, I'm really confused by the behavior of the locks in the unittests.
> E.g. I do not understand why the condition is not locked after a short run
> of the event loop in test_wait (test_locks.ConditionTests).
>
> On trollius this fails (as expected IMO):
>
> FAIL: test_wait (test_locks.ConditionTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/Users/marc/Documents/python/trollius/tests/test_locks.py", line
> 422, in test_wait
> self.assertFalse(cond.locked())
> AssertionError: True is not false
>
>
> Maybe you can shed some light on this and a few other issues:
> https://bitbucket.org/haypo/trollius/pull-request/3/some-fixes-for-test_locks
--
--Guido van Rossum (python.org/~guido)
