← index #5276Issue #8717
Related · high · value 0.515
QUERY · ISSUE

Uasyncio cancelling coroutine takes as long as next scheduled execution

openby kevinkk525opened 2019-10-29updated 2019-10-29

Since I didn't see any open issues about it and jimmo asked, I though I'd open this long-standing issue:

If you cancel a coroutine, the exception won't be raised before the coroutine is scheduled next. This is because it just stays in waitq until it would be executed regularly.
So a coroutine yielding an await uasyncio.sleep(10) will only receive the cancel exception after those 10 seconds have passed.

This results in very late exception handling inside the coroutine but also in canceled coroutines being "stuck" in waitq so the user code has to be careful not to cause a queue overflow if he uses cancellations often.

The fix however requires more than a change to uasyncio, it requires changes to utimeq too so a coroutine can be removed from the queue.
As I understand it Paul has that fixed on his fork.

@peterhinch implemented a high level workaround on his fast_io implementation for making coroutines cancel quickly by using an additional queue but even with that implementation coroutines stay in the utimeq until they are scheduled regularly.

CANDIDATE · ISSUE

There is still a cancellation/race issue in uasyncio wait_for

closedby Kalki70opened 2022-05-31updated 2022-06-17
bugextmod

I know this behavior has been reported before, but I am still seeing it. Tracking a strange condition in our software, where cancelling a task soon after creating it did not work, we found the issue in wait_for and some other reported issues, the last one being #7386

I also found this reported in Python, and a test program mentioned there causes also the issue on micropython : https://bugs.python.org/issue42130

Basically, this code :

import uasyncio as asyncio

async def inner():
    return

async def with_for_coro():
    await asyncio.wait_for(inner(), timeout=100)
    await asyncio.sleep(1)
    print('End of with_for_coro. Should not be reached!')

async def main():
    task = asyncio.create_task(with_for_coro())
    await asyncio.sleep(0)
    assert not task.done()
    task.cancel()
    print('Called task.cancel()')
    await task  # -> You would expect a CancelledError to be raised.

asyncio.run(main())

Running this, no CancelledError is raised when awaiting task in main() and we get this output:

$ micropython cancel.py 
Called task.cancel()
End of with_for_coro. Should not be reached!

Now, if we add a small delay before cancelling, changing for instance to 0.1s:

async def main():
    task = asyncio.create_task(with_for_coro())
    await asyncio.sleep(0.1)

Then we get the expect result :

$ micropython cancel.py 
Called task.cancel()
Traceback (most recent call last):
  File "cancel.py", line 21, in <module>
  File "/usr/lib/micropython/uasyncio/core.py", line 222, in run
  File "/usr/lib/micropython/uasyncio/core.py", line 191, in run_until_complete
  File "/usr/lib/micropython/uasyncio/core.py", line 176, in run_until_complete
  File "cancel.py", line 18, in main
  File "/usr/lib/micropython/uasyncio/task.py", line 145, in __next__
  File "/usr/lib/micropython/uasyncio/core.py", line 183, in run_until_complete
  File "cancel.py", line 9, in with_for_coro
CancelledError: 

This was tested using micropython 1.18

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied