Uasyncio cancelling coroutine takes as long as next scheduled execution
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.
extmod/uasyncio: Fix race with cancelled task waiting on finished task.
This commit fixes a problem with a race between cancellation of task A and
completion of task B, when A waits on B. If task B completes just before
task A is cancelled then the cancellation of A does not work. Instead,
the CancelledError meant to cancel A gets passed through to B (that's
expected behaviour) but B handles it as a "Task exception wasn't retrieved"
scenario, printing out such a message (this is because finished tasks point
their "coro" attribute to themselves to indicate they are done, and
implement the throw() method, but that method inadvertently catches the
CancelledError). The correct behaviour is for B to bounce that
CancelledError back out.
The fix here reworks the "waiting" attribute of Task to be called "state"
and uses it to indicate whether a task is: running and not awaited on,
running and awaited on, finished and not awaited on, or finished and
awaited on. This means the task does not need to point "coro" to itself to
indicate finished, and also allows removal of the throw() method.
A benefit of this is that "Task exception wasn't retrieved" messages can go
back to being able to print the name of the coroutine function.
Fixes issue #7386.