[3.15] gh-151518: Avoid STW starvation of attaching threads (GH-152826)

[tpn]

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:

• Free-threaded debug and TSan: all 31 focused threading, GC, and asyncio tests passed.
• With only the test changes, the unfixed branch hits the 30-second watchdog with 4 and 64 CPUs. The backport passes three runs each with 1, 4, and 64 CPUs.
• Ordinary GIL and WASI builds pass the internal C API helper tests, including test_stop_the_world. Local WASI checks used SDK 34 and Wasmtime 48; the WASI CI job also passed with the branch's configured toolchain.

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?

[hugovk]

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.

[encukou]

@colesbury, do you want to double-check this?
The backport matches the original, but maybe you didn't trigger backports on purpose? The issue only affects artificial stress tests.

[colesbury]

LGTM

[nascheme]

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().

[vstinner]

This seems to break CI for the free-threaded builds

Oh, I suppose that's the issue that I just reported: #159373.