diff options
author | Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> | 2024-05-23 21:27:38 (GMT) |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-05-23 21:27:38 (GMT) |
commit | d98d6b1776996484e05ec6b755a6770977a5000a (patch) | |
tree | efcafc59d80992ed2bd0964c04fef01a380beea4 /Python/pythonrun.c | |
parent | 8fd8cc564bea243e30cc8881a9981ab85e09fe81 (diff) | |
download | cpython-d98d6b1776996484e05ec6b755a6770977a5000a.zip cpython-d98d6b1776996484e05ec6b755a6770977a5000a.tar.gz cpython-d98d6b1776996484e05ec6b755a6770977a5000a.tar.bz2 |
[3.13] gh-118727: Don't drop the GIL in `drop_gil()` unless the current thread holds it (GH-118745) (#119474)
`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 be1dfccdf2c5c7671b8a549e969b8cf7d60d9936)
Co-authored-by: Brett Simmers <swtaarrs@users.noreply.github.com>
Diffstat (limited to 'Python/pythonrun.c')
0 files changed, 0 insertions, 0 deletions