GH-96827: Don't touch closed loops from executor threads - #96837
Conversation
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
kumaraditya303
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
Thanks @gvanrossum for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11. |
Sorry, something went wrong.
|
GH-97690 is a backport of this pull request to the 3.11 branch. |
Sorry, something went wrong.
|
GH-97691 is a backport of this pull request to the 3.10 branch. |
Sorry, something went wrong.
…nGH-96837) * When chaining futures, skip callback if loop closed. * When shutting down an executor, don't wake a closed loop. (cherry picked from commit e9d6376) 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 commit e9d6376) 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.)