Repository navigation
from_thread.run() isn't cancelled on asyncio when the host scope was cancelled before the call (Trio raises Cancelled) #1427
Unanswered
sungbin1015
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I have a sync Starlette endpoint that does some blocking work and then reads the body with
anyio.from_thread.run(request.body), so I was checking what happens if the request's scope gets cancelled while the thread is still busy. On asyncio, if the host scope is cancelled while the worker thread is in blocking code, a laterfrom_thread.run()from that thread isn't cancelled at all.check_cancelled()in the same thread does raise, and on Trio the samefrom_thread.run()raisesCancelledright away. If the thread is already insidefrom_thread.run()when the deadline hits, asyncio cancels it fine, so it's only the "cancelled before the call" case.With
anyio.sleep_foreverinstead ofsleep(2)the asyncio run never finishes. Same result on 4.15.1 and current master, Python 3.12 and 3.13, trio 0.34.0.From a quick look, the scope has already stopped delivering by then (
_cancel_handleisNone, since the only task in it is parked in to_thread's shield), and the taskfrom_thread.run()creates gets added toscope._taskswithout anything restarting delivery.tg.start_soon()called from a shielded scope inside an already-cancelled task group does the same thing on asyncio.Is
from_thread.run()supposed to raise here like it does on Trio, or should I treatcheck_cancelled()as the only reliable signal once the host may have been cancelled?All reactions