The asyncadapter util now has get_running_loop #151
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The asyncadapter is used by loops that are not async by default, like Qt and Wx. This PR adds a
get_running_loop()function to that module, so we can integrate better with sniffio. In particular, in wgpu-py I want to be able to do:This code works the same for both asyncio and our adapter. (Trio works differently; we'll handle that with an if statement.)
I explored several options for "integrating" the rendercanvas loop with wgpu-py. My first inclination was to go for something like
rendercanvas.get_current_loop(), but it turns out that it's hard to establish when a loop becomes 'active'. E.g. it may already be running in an interactive session. So it felt like it was hard to keep this properly in sync.The current solution that goes via asyncio, is nice, because you get exactly the loop for the current code invocation, which makes it very robust, even if ppl go do weird things, like running a loop from another loop.