Skip to content

gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization #105805

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
gpshead merged 17 commits into from
Oct 2, 2024
Merged

gh-87135: Hang non-main threads that attempt to acquire the GIL during finalization #105805

Changes from 1 commit
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
30c8135
gh-87135: Hang non-main threads that attempt to acquire the GIL durin…
jbms Jun 14, 2023
3c3d552
Merge branch 'main' into new-gil-hang
gpshead Sep 26, 2024
da37473
docs fixups
gpshead Sep 26, 2024
3ec84f6
doc fixup, use the new next versionchanged docs feature.
gpshead Sep 26, 2024
2bc54ca
deprecated in 3.14
gpshead Sep 26, 2024
80d2c49
use the gh- ref instead of bpo- everywhere.
gpshead Sep 26, 2024
9b1eaf6
Remove wrong comments, improve others.
gpshead Sep 26, 2024
cf76777
expand the comment.
gpshead Sep 26, 2024
2dae315
more docs
gpshead Sep 26, 2024
28118a0
update a comment
gpshead Sep 27, 2024
87249ab
address review comments.
gpshead Oct 1, 2024
afe5507
include what you use for pause()
gpshead Oct 2, 2024
e05a127
improve comments.
gpshead Oct 2, 2024
ec0e07a
Merge branch 'main' into new-gil-hang
gpshead Oct 2, 2024
1569700
wasi doesn't have pause()?!? try sleep(9999999)
gpshead Oct 2, 2024
ac3b2ce
more wasi workarounds.
gpshead Oct 2, 2024
ac3d2be
Skip the new test under TSAN (and MSAN).
gpshead Oct 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
more docs
  • Loading branch information
@gpshead
gpshead committed Sep 26, 2024
commit 2dae315aad7fd599b87cb84fe7c1f9ff82de0f60
18 changes: 13 additions & 5 deletions Doc/c-api/init.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -981,11 +981,19 @@ If any thread, other than the finalization thread, attempts to acquire the GIL
during finalization, either explicitly via :c:func:`PyGILState_Ensure`,
:c:macro:`Py_END_ALLOW_THREADS`, :c:func:`PyEval_AcquireThread`, or
:c:func:`PyEval_AcquireLock`, or implicitly when the interpreter attempts to
reacquire it after having yielded it, the thread enters a permanently blocked
state where it remains until the program exits. In most cases this is harmless,
but this can result in deadlock if a later stage of finalization attempts to
acquire a lock owned by the blocked thread, or otherwise waits on the blocked
thread.
reacquire it after having yielded it, the thread enters **a permanently blocked
state** where it remains until the program exits. In most cases this is
harmless, but this can result in deadlock if a later stage of finalization
attempts to acquire a lock owned by the blocked thread, or otherwise waits on
the blocked thread.

Gross? Yes. This prevents random crashes and/or unexpectedly skipped C++
finalizations further up the call stack when such threads were forcably exited
Comment thread
gpshead marked this conversation as resolved.
Outdated
here in CPython 3.13 and earlier. The CPython runtime GIL acquiring C APIs
have never had any error reporting or handling expectations at GIL acquisition
time that would've allowed for graceful exit from this situation. Changing that
would require new stable C APIs and rewriting the majority of C code in the
CPython ecosystem to use those with error handling.


High-level API
Expand Down