gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization - #105805
Conversation
… during finalization
|
@colesbury and/or @mpage, and @ericsnowcurrently - can you take a look at this PR? (FWIW, Eric's already gone over it with my on screen at the core dev sprint here) |
|
Blocking daemon threads after the VM has been finalized seems less error prone than forcing the threads to exit. I believe this is also how the JVM handles the same situation, so there's some precedence for this approach. While we're here, I think this might be a good time to also fix the issues with threads referencing their |
if any more, i'll just skip the test on wasi.
Linking to the filed pre-existing known issue.
That goes beyond the scope of what I want to accomplish with this PR - which I believe might mostly be a candidate for backporting as a bug fix (I'll see what the RMs think). I think it is a good followup issue though - #124878 for starters but that might turn into a couple of different things to chase down as well. |
|
@Yhg1s what's your opinion on the viability of backporting this as a bugfix to 3.13 and 3.12 patch releases? People who actually encounter this in the form of strange crashes from threads during shutdown have been wanting it for years. I wouldn't call it common, just a thorn in some classes of applications side. (In terms of impact I'd elide marking the deprecated C API as deprecated in the backports - otherwise I expect most of this to apply relatively easily given that it was originally authored on a |
|
Sorry, @jbms and @gpshead, I could not cleanly backport this to |
|
Sorry, @jbms and @gpshead, I could not cleanly backport this to |
|
I expected the backport automation to fail and need edits regardless even if it hadn't. I'll be taking care of them. :) |
|
Triage: @gpshead reminder about the backports :) |
|
Please don't forget about backport. @gpshead |
…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>
|
GH-137827 is a backport of this pull request to the 3.13 branch. |
…L during finalization (GH-105805) (GH-137827) * [3.13] gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization (GH-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> * state "3.13.7 and earlier" * backport: do not add the deprecated marker * fix Py_IsFinalizing doc ref --------- Co-authored-by: Jeremy Maitin-Shepard <jeremy@jeremyms.com>

This splits off the change from #28525 to hang threads that attempt to acquire the GIL during interpreter shutdown, but does not introduce any new public APIs.
📚 Documentation preview 📚: https://cpython-previews--105805.org.readthedocs.build/