NotificationsYou must be signed in to change notification settings
Fork32.4k
Star67.9k

[3.13] gh-118727: Don't drop the GIL in`drop_gil()` unless the current thread holds it (GH-118745)#119474

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.

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

Already on GitHub?Sign in to your account

Jump to bottom

Merged

colesbury merged 1 commit intopython:3.13frommiss-islington:backport-be1dfcc-3.13

May 23, 2024

Merged

[3.13] gh-118727: Don't drop the GIL in`drop_gil()` unless the current thread holds it (GH-118745)#119474

colesbury merged 1 commit intopython:3.13frommiss-islington:backport-be1dfcc-3.13

May 23, 2024

Conversation

Copy link

Contributor

miss-islington commentedMay 23, 2024•
edited by bedevere-appbot
Loading

drop_gil() assumes that its caller is attached, which means that the current
thread holds the GIL if and only if the GIL is enabled, and the enabled-state
of the GIL won't change. This isn't true, though, becausedetach_thread()
calls_PyEval_ReleaseLock() after detaching and
_PyThreadState_DeleteCurrent() calls it after removing the current thread
from consideration for stop-the-world requests (effectively detaching it).

Fix this by remembering whether or not a thread acquired the GIL when it last
attached, inPyThreadState._status.holds_gil, and check this indrop_gil()
instead ofgil->enabled.

This fixes a crash intest_multiprocessing_pool_circular_import(), so I've
reenabled it.
(cherry picked from commitbe1dfcc)

Co-authored-by: Brett Simmersswtaarrs@users.noreply.github.com

Issue:Crash inPyThreadState_DeleteCurrent: drop_gil: GIL is not locked (free-threading) #118727

pythongh-118727: Don't drop the GIL indrop_gil()unless the curren…

e53ddcf

…t thread holds it (pythonGH-118745)`drop_gil()` assumes that its caller is attached, which means that the currentthread holds the GIL if and only if the GIL is enabled, and the enabled-stateof the GIL won't change. This isn't true, though, because `detach_thread()`calls `_PyEval_ReleaseLock()` after detaching and`_PyThreadState_DeleteCurrent()` calls it after removing the current threadfrom consideration for stop-the-world requests (effectively detaching it).Fix this by remembering whether or not a thread acquired the GIL when it lastattached, in `PyThreadState._status.holds_gil`, and check this in `drop_gil()`instead of `gil->enabled`.This fixes a crash in `test_multiprocessing_pool_circular_import()`, so I'vereenabled it.(cherry picked from commitbe1dfcc)Co-authored-by: Brett Simmers <swtaarrs@users.noreply.github.com>