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.
This will quit the GLib main loop in two events:
See #1 for discussion on motivation for this. I think that those should be all reasons why the loop would need stopping from Python callbacks.
Note that there is one case left that is not covered -- if a Future is created the Old Way (as
asyncio.Future()
, not recommended any more), giving it a result will not give tasks blocked on it a chance to run until something else nudges the GLib main loop. This could be circumvented by monkey patchingasyncio.Future
to use our own future, but that's not really how things should be. We might want to offer an "install" function that sets the loop and replaces the Future class, but using that should be a conscious decision by the user and not just the way it's done so everything magically works.Here's an extension of the demo in #1 that uses all the cases: