-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for scoped cancellation/timeouts when calling into asyncio code #415
Comments
Sorry I missed this. Can you elaborate on what difficulties you are experiencing? Is level cancellation the issue? I'm not sure this is related, but I have indeed planned a utility function to call into asyncio, but I'm not sure how to implement that with trio. |
I haven't actually tried exercising naive calls into asyncio thoroughly enough to run into any issues, I just assume something can go wrong due to this passage from the docs:
Something likely related to level cancelation and scoped timeouts. Or did I misunderstand what that means? Now that I look at it again, it can indeed be interpreted as "tasks created via
I'm talking more along the lines of calling into the current backend (whatever that may be) while preserving anyio semantics, rather than into asyncio specifically. |
I think there is some sort of confusion here. If you're using asyncio libraries to spawn tasks, they will expect those tasks to adhere to the native asyncio cancellation rules, yes? Why would you want them to use anyio semantics instead? Did I understand something wrong? |
I'm not spawning asyncio tasks, at least not directly. Let's consider a concrete example. Suppose I want to use |
Depends. The biggest gotcha is whether it uses |
Right, so a utility is necessary that will convert level cancellation into edge cancellation, possibly by awaiting in a separate asyncio task as |
Yeah, you need something extra for that. Your implementation seems a bit unnecessarily complex though – wouldn't it be enough to just |
My original motivation for doing it this way was to avoid awaiting on an incomplete asyncio task from anyio task because I'm not sure what the cancellation semantics of such a composition are supposed to be. Won't doing as you suggest cause level cancellation within asyncio task, same as awaiting the wrapped coroutine directly? |
I haven't verified that, but you could be right. I think the question becomes: what should the host task do after the initial cancellation? Should it wait for the child task to finish, in a shielded cancel scope? Or should the native task be orphaned? |
asyncio doesn't like unretrieved task/future results either (at least when the results are exceptions), so I believe orphaning is not a good idea, at least not by default. If asyncio task decides to ignore cancellation, we'll be stuck waiting for it, but that's not something well-behaved asyncio code generally does. |
I'm using anyio with asyncio backend since I need some asyncio-based libs for which no anyio or trio equivalents of comparable quality exist yet. However, since asyncio code doesn't respect scoped cancellation/timeouts of anyio, calling into them is quite awkward and error-prone. I came up with the following generic utility to deal with this:
A call into asyncio code wrapped with
call_into_asyncio
will respect scoped cancellation and timeouts. It appears to work correctly for my purposes. Are there any edge cases or other issues with this approach that I'm missing? I'm surprised something like this doesn't already exists in anyio.The text was updated successfully, but these errors were encountered: