Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-108724: Fix _PySemaphore_Wait call during thread deletion #116483

Merged
merged 3 commits into from
Mar 8, 2024

Conversation

colesbury
Copy link
Contributor

@colesbury colesbury commented Mar 7, 2024

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 colesbury force-pushed the gh-108724-sema-wait branch from e4aa866 to 6a6ca9e Compare March 7, 2024 23:29
@colesbury colesbury changed the title gh-116480: Fix _PySemaphore_Wait call during thread deletion gh-108724: Fix _PySemaphore_Wait call during thread deletion Mar 7, 2024
Copy link
Member

@ericsnowcurrently ericsnowcurrently left a comment

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.

Python/parking_lot.c Outdated Show resolved Hide resolved
colesbury and others added 2 commits March 8, 2024 14:52
Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
@colesbury
Copy link
Contributor Author

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.

@colesbury colesbury merged commit 3cdfdc0 into python:main Mar 8, 2024
32 checks passed
@colesbury colesbury deleted the gh-108724-sema-wait branch March 8, 2024 20:26
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants