This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: condition lock not re-acquired
Type: behavior Stage: resolved
Components: asyncio Versions: Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder: wait_for(future, ...) should wait for the future (even if a timeout occurs)
View: 32751
Assigned To: Nosy List: asvetlov, christof, miss-islington, yselivanov
Priority: normal Keywords: patch

Created on 2018-05-24 19:10 by christof, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 7216 merged Elvis.Pranskevichus, 2018-05-29 19:40
PR 7223 merged miss-islington, 2018-05-29 21:32
Messages (5)
msg317604 - (view) Author: christof (christof) Date: 2018-05-24 19:10

I have a simple code which triggers a timeout if a task did not complete

import asyncio

async def task_timeout():
    condition = asyncio.Condition()
    with await condition:
            await asyncio.wait_for(condition.wait(), timeout=4)
        except asyncio.TimeoutError as e:
            print("timeout reached")
            # uncomment this line to make the code work
            # await asyncio.sleep(0)

f = asyncio.ensure_future(task_timeout())

loop= asyncio.get_event_loop()

It throws an exception when leaving the scope for the condition because it expects the lock to be acquired:

RuntimeError: Lock is not acquired.

If you uncomment the line to sleep, it will work because it will continue in the coroutine Condition.wait and call:
 yield from self.acquire() => line 355

I think this is a bug and that this behaviour is not the expected one.
msg317608 - (view) Author: christof (christof) Date: 2018-05-24 19:53
In my previous comment, what I want to implement is not a timeout for a task to complete but more precisely a timeout triggered if the coroutine was not wake up by a notify on the condition.
msg318063 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2018-05-29 18:24
This is caused by wait_for not waiting for the cancelled task. tracks that bug.
msg318096 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2018-05-29 21:31
New changeset e2b340ab4196e1beb902327f503574b5d7369185 by Yury Selivanov (Elvis Pranskevichus) in branch 'master':
bpo-32751: Wait for task cancellation in asyncio.wait_for() (GH-7216)
msg318131 - (view) Author: miss-islington (miss-islington) Date: 2018-05-29 22:37
New changeset d8948c5e09c4a2a818f6f6cfaf8064f2c2138fa5 by Miss Islington (bot) in branch '3.7':
bpo-32751: Wait for task cancellation in asyncio.wait_for() (GH-7216)
Date User Action Args
2022-04-11 14:59:00adminsetgithub: 77819
2018-05-30 01:01:18yselivanovsetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2018-05-29 22:37:09miss-islingtonsetnosy: + miss-islington
messages: + msg318131
2018-05-29 21:32:27miss-islingtonsetpull_requests: + pull_request6855
2018-05-29 21:31:05yselivanovsetmessages: + msg318096
2018-05-29 19:40:58Elvis.Pranskevichussetkeywords: + patch
stage: patch review
pull_requests: + pull_request6849
2018-05-29 18:24:04yselivanovsetsuperseder: wait_for(future, ...) should wait for the future (even if a timeout occurs)
messages: + msg318063
2018-05-24 19:53:41christofsetmessages: + msg317608
2018-05-24 19:10:23christofcreate