mirror of
https://github.com/python/cpython.git
synced 2025-11-01 06:01:29 +00:00
[3.13] gh-87135: Hang non-main threads that attempt to acquire the GIL 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 8cc5aa47ee)
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 commit is contained in:
parent
f2b7954ce0
commit
9face218e7
10 changed files with 247 additions and 28 deletions
|
|
@ -2069,7 +2069,7 @@ _Py_Finalize(_PyRuntimeState *runtime)
|
|||
/* Ensure that remaining threads are detached */
|
||||
_PyEval_StopTheWorldAll(runtime);
|
||||
|
||||
/* Remaining daemon threads will automatically exit
|
||||
/* Remaining daemon threads will be trapped in PyThread_hang_thread
|
||||
when they attempt to take the GIL (ex: PyEval_RestoreThread()). */
|
||||
_PyInterpreterState_SetFinalizing(tstate->interp, tstate);
|
||||
_PyRuntimeState_SetFinalizing(runtime, tstate);
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue