| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
🤖 New build scheduled with the buildbot fleet by @kumaraditya303 for commit 1e6a87b 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
There's one case that could be problematic but (ISTM) is highly unlikely: some other thread might call PyThreadState_Delete*() on one of the existing thread states, which would modify the linked list while we're walking it here. We could mitigate that (very small) risk by checking in those functions if the interpreter is finalizing and returning immediately (or blocking) if it is. FWIW, the status quo is already deficient in that case, and this PR only slightly adds to the problem. Regardless, the risk is fairly minimal so we can address that separately.
(Before merging, would you mind just double-checking that the risk actually is minimal? 😄)
One observation: the lock isn't strictly necessary here. It's needed for one of the following:
At this point in interpreter finalization, neither of those things should be happening. So it may make sense to disallow them (or ignore/block, in the case of the second one). Alternately we could give each interpreter it's own lock (e.g. PyInterpreterState.threads.mutex) to use when managing its thread states, as opposed to reusing the global "HEAD" lock like we currently do.
Sorry, something went wrong.
Yeah, I too noticed that but I am not concerned about that as at runtime shutdown such code is already unsafe and can crash or result in hang etc. Regardless I'll address that separately in a new issue and get this fixed first. Thanks for the review. |
Sorry, something went wrong.
|
The buildbots failures are unrelated so merging. https://buildbot.python.org/all/#/builders/259/builds/681/steps/5/logs/stdio |
Sorry, something went wrong.
|
Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9, 3.10, 3.11. |
Sorry, something went wrong.
|
Sorry, @kumaraditya303, I could not cleanly backport this to 3.11 due to a conflict. |
Sorry, something went wrong.
|
Sorry @kumaraditya303, I had trouble checking out the 3.10 backport branch. |
Sorry, something went wrong.
|
Sorry, @kumaraditya303, I could not cleanly backport this to 3.9 due to a conflict. |
Sorry, something went wrong.
|
GH-102234 is a backport of this pull request to the 3.11 branch. |
Sorry, something went wrong.
|
GH-102235 is a backport of this pull request to the 3.10 branch. |
Sorry, something went wrong.
|
GH-102236 is a backport of this pull request to the 3.9 branch. |
Sorry, something went wrong.
…states (pythonGH-102222). (cherry picked from commit 5f11478) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
… states (pythonGH-102222). (cherry picked from commit 5f11478) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
… states (pythonGH-102222). (cherry picked from commit 5f11478) Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
|
Sorry, something went wrong.
|
GH-102236 is a backport of this pull request to the 3.9 branch. |
Sorry, something went wrong.
…GH-102222) (#102236) (cherry picked from commit 5f11478)
… state… (python#102235) [3.10] pythonGH-102126: fix deadlock at shutdown when clearing thread states (pythonGH-102222). (cherry picked from commit 5f11478)
… state… (python#102235) [3.10] pythonGH-102126: fix deadlock at shutdown when clearing thread states (pythonGH-102222). (cherry picked from commit 5f11478)
| Back | FazBrowse Home | New Git URL |
Uh oh!
There was an error while loading. Please reload this page.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.