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 }})

colesbury

Contributor

@colesbury colesbury commented

Mar 7, 2024

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.

@colesbury

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 colesbury changed the titlegh-116480: Fix _PySemaphore_Wait call during thread deletion gh-108724: Fix _PySemaphore_Wait call during thread deletion

Mar 7, 2024

ericsnowcurrently

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.

@colesbury @ericsnowcurrently

Co-authored-by: Eric Snow ericsnowcurrently@gmail.com

@colesbury

@colesbury

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

Mar 25, 2024

…ython#116483)

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

Apr 17, 2024

…ython#116483)

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

@colesbury @ericsnowcurrently