diff options
| author | Jeremy Maitin-Shepard <jeremy@jeremyms.com> | 2024-10-02 16:17:49 (GMT) |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-10-02 16:17:49 (GMT) |
| commit | 8cc5aa47ee464ddfd8da5461edecf4a5c72df2ff (patch) | |
| tree | 41cdda0e2be153a4363cec9d616856444b306273 /Misc/NEWS.d/next/C API | |
| parent | 113b2d7583cdbf79da18e696f299a9aca24b599b (diff) | |
| download | cpython-8cc5aa47ee464ddfd8da5461edecf4a5c72df2ff.zip cpython-8cc5aa47ee464ddfd8da5461edecf4a5c72df2ff.tar.gz cpython-8cc5aa47ee464ddfd8da5461edecf4a5c72df2ff.tar.bz2 | |
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.
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Diffstat (limited to 'Misc/NEWS.d/next/C API')
| -rw-r--r-- | Misc/NEWS.d/next/C API/2022-08-05-19-41-20.gh-issue-87135.SCNBYj.rst | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/Misc/NEWS.d/next/C API/2022-08-05-19-41-20.gh-issue-87135.SCNBYj.rst b/Misc/NEWS.d/next/C API/2022-08-05-19-41-20.gh-issue-87135.SCNBYj.rst new file mode 100644 index 0000000..6387d69 --- /dev/null +++ b/Misc/NEWS.d/next/C API/2022-08-05-19-41-20.gh-issue-87135.SCNBYj.rst @@ -0,0 +1,15 @@ +Attempting to acquire the GIL after runtime finalization has begun in a +different thread now causes the thread to hang rather than terminate, which +avoids potential crashes or memory corruption caused by attempting to +terminate a thread that is running code not specifically designed to support +termination. In most cases this hanging is harmless since the process will +soon exit anyway. + +The ``PyThread_exit_thread`` function is now deprecated. Its behavior is +inconsistent across platforms, and it can only be used safely in the +unlikely case that every function in the entire call stack has been designed +to support the platform-dependent termination mechanism. It is recommended +that users of this function change their design to not require thread +termination. In the unlikely case that thread termination is needed and can +be done safely, users may migrate to calling platform-specific APIs such as +``pthread_exit`` (POSIX) or ``_endthreadex`` (Windows) directly. |