[3.13] gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization (GH-105805)#137827
Conversation
…the GIL during finalization (pythonGH-105805) Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This marks the `PyThread_exit_thread` public C API as deprecated as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option. (cherry picked from commit 8cc5aa4) Co-authored-by: Jeremy Maitin-Shepard <jeremy@jeremyms.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead
force-pushed
the
backport-8cc5aa4-3.13
branch
from
4f77306 to
977b0d4
Compare
gpshead
added
type-bug
gpshead
force-pushed
the
backport-8cc5aa4-3.13
branch
from
977b0d4 to
f412737
Compare
gpshead
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @gpshead for commit f412737 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F137827%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
serhiy-storchaka
left a comment
serhiy-storchaka
left a comment
There was a problem hiding this comment.
I cannot say it LGTM, but it looks less bad than anything else.
|
I'll leave this PR around for reference, but do not intend to merge it so late in the 3.13 release cycle even though I believe this least bad option is the only viable one. It is a behavior change, even if the existing behavior is an undertiministic sometimes crashing or sometimes working. See #87135 (comment) and #123940 (comment) for rationale from @encukou about invasiveness of such a change as in a bugfix release. |
4 participants
Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This backport documents that the
PyThread_exit_threadpublic C API should not be used (deprecated in 3.14) as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option.(cherry picked from commit 8cc5aa4)
📚 Documentation preview 📚: https://cpython-previews--137827.org.readthedocs.build/