gh-108724: Fix _PySemaphore_Wait call during thread deletion by colesbury · Pull Request #116483 · python/cpython (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Contributor
colesbury commented
•
edited by bedevere-appbot
Loading
In general, when _PyThreadState_GET()
is non-NULL then the current thread is "attached", but there is a small window during PyThreadState_DeleteCurrent()
where that's not true: tstate_delete_common()
is called when the thread is detached, but before current_fast_clear().
This updates _PySemaphore_Wait()
to handle that case.
In general, when _PyThreadState_GET()
is non-NULL then the current
thread is "attached", but there is a small window during
PyThreadState_DeleteCurrent()
where that's not true:
tstate_delete_common is called when the thread is detached, but before
current_fast_clear().
This updates _PySemaphore_Wait() to handle that case.
colesbury changed the title
gh-116480: Fix _PySemaphore_Wait call during thread deletion gh-108724: Fix _PySemaphore_Wait call during thread deletion
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I have one very minor comment about the applicability of the PyEval_ReleaseThread()
call. Feel free to address it (or not) how you think makes sense.
As to the motivation for this PR, should we aim for eliminating the small window you described in PR description? It vaguely feels like something is our of whack with that.
Co-authored-by: Eric Snow ericsnowcurrently@gmail.com
As to the motivation for this PR, should we aim for eliminating the small window you described in PR description? It vaguely feels like something is our of whack with that.
Yeah, I'll put up another PR that does that as well.
adorilson pushed a commit to adorilson/cpython that referenced this pull request
In general, when _PyThreadState_GET()
is non-NULL then the current
thread is "attached", but there is a small window during
PyThreadState_DeleteCurrent()
where that's not true:
tstate_delete_common() is called when the thread is detached, but before
current_fast_clear().
Co-authored-by: Eric Snow ericsnowcurrently@gmail.com
diegorusso pushed a commit to diegorusso/cpython that referenced this pull request
In general, when _PyThreadState_GET()
is non-NULL then the current
thread is "attached", but there is a small window during
PyThreadState_DeleteCurrent()
where that's not true:
tstate_delete_common() is called when the thread is detached, but before
current_fast_clear().
Co-authored-by: Eric Snow ericsnowcurrently@gmail.com
2 participants