gh-104341: Call _PyEval_ReleaseLock() with NULL When Finalizing the Current Thread#105109
Conversation
I think we're good to go: no objections from me. I never assume I can have full confidence about modifications to this code, but CI and buildbots and ultimately beta2 testing should reveal more if anything else lurks... |
Sorry, something went wrong.
|
Thanks you! |
Sorry, something went wrong.
|
Thanks @ericsnowcurrently for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
Sorry, something went wrong.
|
Sorry @ericsnowcurrently, I had trouble checking out the |
Sorry, something went wrong.
|
Thanks @ericsnowcurrently for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12. |
Sorry, something went wrong.
… the Current Thread (pythongh-105109) This avoids the problematic race in drop_gil() by skipping the FORCE_SWITCHING code there for finalizing threads. (The idea for this approach came out of discussions with @markshannon.) (cherry picked from commit 3698fda) Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
…g the Current Thread (gh-105109) (gh-105209) This avoids the problematic race in drop_gil() by skipping the FORCE_SWITCHING code there for finalizing threads. (The idea for this approach came out of discussions with @markshannon.) (cherry picked from commit 3698fda) Co-authored-by: Eric Snow ericsnowcurrently@gmail.com
This avoids the problematic race in
drop_gil()by skipping theFORCE_SWITCHINGcode there for finalizing threads.This is a much simpler approach to solving the race than in other PRs I've posted. I'd still like to pursue some of those other ideas but that can be done separately for 3.13+.
(The idea for this approach came out of discussions with @markshannon.)