Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.1k
GH-96827: Don't touch closed loops from executor threads#96837
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
At this point (after investing over an hour of my time) I feel it's not worth it to try and come up with a test that reproduces the original issue. The changes appear straightforward enough: in certain edge cases don't attempt to set a future's state when its loop is already closed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM
Thanks@gvanrossum for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11. |
bedevere-bot commentedSep 30, 2022
GH-97690 is a backport of this pull request to the3.11 branch. |
bedevere-bot commentedSep 30, 2022
GH-97691 is a backport of this pull request to the3.10 branch. |
…nGH-96837)* When chaining futures, skip callback if loop closed.* When shutting down an executor, don't wake a closed loop.(cherry picked from commite9d6376)Co-authored-by: Guido van Rossum <guido@python.org>
…nGH-96837)* When chaining futures, skip callback if loop closed.* When shutting down an executor, don't wake a closed loop.(cherry picked from commite9d6376)Co-authored-by: Guido van Rossum <guido@python.org>
…n#96837)* When chaining futures, skip callback if loop closed.* When shutting down an executor, don't wake a closed loop.
It's possible for an event loop's default executor to survive the loop. When the executor is finally shut down, a few things try to wake up the loop, and nasty RuntimeErrors are printed. But there's nothing the executor can do about that, so let's just not even try.
This is a draft PR because I haven't figured out a way to test this properly. (There's a repro in the issue,GH-96827.)