| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
… world Move the threads.head assert in handle_thread_shutdown_exception to after _PyEval_StopTheWorld so it does not race tstate_delete_common (TSAN-0034).
Sorry, something went wrong.
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: fa67e46142 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Sorry, something went wrong.
|
Closing this PR. Thank you for the review attention. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Summary
Fix TSAN-0034 from the free-threading data-race umbrella gh-153852: a debug-only race on interp->threads.head during finalization.
What the issue is
In handle_thread_shutdown_exception (Python/pylifecycle.c):
The comment below correctly says the world-stopped loop does not need locking — but the assert runs before STW. A racing exiting thread in tstate_delete_common can mutate the list under HEAD_LOCK, and TSan reports a data race on the assert's load. Severity is low (debug assert only; NDEBUG strips it), but it is a real race on a free-threaded --with-pydebug build and pollutes TSan signal.
Why I solved it that way
How I did it
NEWS under Core and Builtins referencing gh-153852 (TSAN-0034).
Impact
Testing plan
Everything else
Requested reviewers (subject-matter experts)
Could the following SMEs take a look when convenient (I cannot formally request reviews from this fork account):
Thank you!