"loop argument must agree with lock" instantiating asyncio.Condition #89579

Activity

1. simonw commented on Oct 8, 2021

   

   simonwmannequin

   on Oct 8, 2021

   MannequinAuthor

   More actions

   In Python 3.10 it is not possible to instantiate an asyncio.Condition that wraps an asyncio.Lock without raising a "loop argument must agree with lock" exception.

   This code raises that exception:

       asyncio.Condition(asyncio.Lock())

   This worked in previous Python versions.

   Note that the error only occurs if an event loop is running. Here's a simple script that replicates the problem:

       import asyncio
   
       # This runs without an exception:
       print(asyncio.Condition(asyncio.Lock()))
   
       # This does not work:
       async def example():
           print(asyncio.Condition(asyncio.Lock()))
   
       # This raises "ValueError: loop argument must agree with lock":
       asyncio.run(example())
2. simonw

   added

   3.10 (EOL)end of lifeend of life

   topic-asyncio

   on Oct 8, 2021
3. simonw commented on Oct 8, 2021

   

   simonwmannequin

   on Oct 8, 2021

   MannequinAuthor

   More actions

   I ran across this issue while trying to use the https://pypi.org/project/janus/ locking library with Python 3.10 - see my issue on their tracker here: aio-libs/janus#358
4. simonw commented on Oct 8, 2021

   

   simonwmannequin

   on Oct 8, 2021

   MannequinAuthor

   More actions

   It looks like the relevant test is here:

   cpython/Lib/test/test_asyncio/test_locks.py

   Lines 722 to 727 in a1092f6

   	def test_explicit_lock(self):
   	lock = asyncio.Lock()
   	cond = asyncio.Condition(lock)
   	self.assertIs(cond._lock, lock)
   	self.assertIs(cond._loop, lock._loop)

   See More

       def test_explicit_lock(self):
           lock = asyncio.Lock()
           cond = asyncio.Condition(lock)
   
           self.assertIs(cond._lock, lock)
           self.assertIs(cond._loop, lock._loop)

   But... that test doesn't appear to run inside an event loop, so it's not covering the behaviour described in this issue.
5. ambv commented on Oct 8, 2021

   

   ambv

   on Oct 8, 2021

   Contributor

   More actions

   Issue confirmed. The problem is that Condition.__init__ compares its own loop with Lock's internal _loop attribute. That attribute is set to None unless the lock waited to be acquired.

   uriyyo, Andrew, Yury, since it's pretty likely that Lock objects will now have _loop set to None, I think the check for "loop agreement" in Condition is kind of useless. So I propose to simply remove it. It's the only such check in all of asyncio.

   If you insist on keeping the loop check, it should special-case _loop is None.

   Simon, thanks for your detailed report! As a backwards-compatible workaround till we get a fix in, your user code can do the following:

   >>> l = asyncio.Lock()
   >>> getattr(l, '_get_loop', lambda: None)()
   <_UnixSelectorEventLoop running=True closed=False debug=False>

   You can use such lock without issues now:

   >>> asyncio.Condition(l)
   <asyncio.locks.Condition object at 0x10c05bee0 [unlocked]>

   Alternatively, if the above disgusts you and you only want to trigger public APIs, you can do this dance:

   >>> l = asyncio.Lock()
   >>> await l.acquire()  # first acquire will just work
   True
   >>> try:
   ...   # second acquire will block so we time it out
   ...   await asyncio.wait_for(l.acquire(), 0.1)
   ... except asyncio.TimeoutError:
   ...   pass
   ...
   >>> l.release()

   Now the lock is fully initialized and we can use it:

   >> c = asyncio.Condition(l)

   Both workarounds should be compatible with Python 3.7+ asyncio.
6. corona10

   added

   3.11only security fixesonly security fixes

   on Oct 10, 2021
7. serhiy-storchaka commented on Oct 10, 2021

   

   serhiy-storchaka

   on Oct 10, 2021

   Member

   More actions

   New changeset 1a78924 by Joongi Kim in branch 'main':
   bpo-45416: Fix use of asyncio.Condition() with explicit Lock objects (GH-28850)
   1a78924
8. miss-islington commented on Oct 10, 2021

   

   miss-islington

   on Oct 10, 2021

   Contributor

   More actions

   New changeset 164dddf by Miss Islington (bot) in branch '3.10':
   bpo-45416: Fix use of asyncio.Condition() with explicit Lock objects (GH-28850)
   164dddf
9. asvetlov commented on Oct 12, 2021

   

   asvetlov

   on Oct 12, 2021

   Contributor

   More actions

   Thanks, guys!
10. asvetlov

    closed this as completedon Oct 12, 2021
11. asvetlov

    closed this as completedon Oct 12, 2021
12. ezio-melotti

    transferred this issue fromon Apr 10, 2022