Skip to content

Conversation

@miss-islington
Copy link
Contributor

@miss-islington miss-islington commented May 23, 2024

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, because detach_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, 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've
reenabled it.
(cherry picked from commit be1dfcc)

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

…t thread holds it (pythonGH-118745) `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, because `detach_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, 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've reenabled it. (cherry picked from commit be1dfcc) Co-authored-by: Brett Simmers <swtaarrs@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

3 participants