Repository navigation
[3.15] gh-151518: Avoid STW starvation of attaching threads (GH-152826) - #158186
encukou merged 1 commit into
Conversation
Sorry, something went wrong.
…thonGH-152826) Preserve active attach waiters across successive stop-the-world pauses so a tight collection loop cannot keep them from making progress. Keep the waiter-aware resume operation local to pystate.c because this branch does not have the newer BRC suspend and resume helpers. (cherry picked from commit f156510)
|
This can go into 3.15.0 if not too risky, and PRs need core peer review during the RC, see https://discuss.python.org/t/the-3-15-branch-is-locked-for-rc1/108389. |
Sorry, something went wrong.
|
@colesbury, do you want to double-check this? |
Sorry, something went wrong.
colesbury
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
This seems to break CI for the free-threaded builds. I see: Python/pystate.c:2404: void _PyThreadState_ResumeDetached(PyThreadState *): Assertion `_Py_atomic_load_int_relaxed(&tstate->state) == _Py_THREAD_SUSPENDED' failed. The 3.15 branch does have the BRC suspend/resume helpers (added by e538c26). The fix suggested by Claude is to basically move the code from tstate_resume() into _PyThreadState_ResumeDetached() and remove tstate_resume(). |
Sorry, something went wrong.
Oh, I suppose that's the issue that I just reported: #159373. |
Sorry, something went wrong.
Backport of gh-152826, merged as f156510, for gh-151518.
A tight loop of stop-the-world pauses can repeatedly suspend a thread trying to reattach after sleeping, preventing it from returning and stopping the loop. This was found during intentional numba-cuda GC stress on many-core machines. The fix preserves active attach waiters across successive pauses so they have a chance to run.
This branch predates gh-157839, so the waiter-aware resume operation is a private helper in pystate.c. The attachment changes, regression test, and guard that avoids blocking waits on WASI are carried over from the merged fix.
Validation:
CI note: the required Tests workflow passed. The Intel macOS JIT debug job exceeded its one-hour limit; its log is unavailable, so the cause is not yet known. A targeted retry is running on the unchanged commit. The other 18 JIT jobs passed.
@hugovk Given the 3.15 RC freeze, should this go into 3.15.0 or wait for the first maintenance release?