gh-104341: Fix threading Module Shutdown#104560
gh-104341: Fix threading Module Shutdown#104560ericsnowcurrently wants to merge 12 commits intopython:mainfrom
Conversation
| PyThread_acquire_lock(threads->mutex, WAIT_LOCK); | ||
| while (threads->head != NULL) { | ||
| PyThread_release_lock(threads->mutex); | ||
| // XXX Sleep? | ||
| PyThread_acquire_lock(threads->mutex, WAIT_LOCK); | ||
| } | ||
| PyThread_release_lock(threads->mutex); |
There was a problem hiding this comment.
FYI, this doesn't feel right. I'm going to look at what my options are. A condvar would work, but that doesn't seem to be something we do in CPython outside the GIL.
(I'm also open to ideas.)
There was a problem hiding this comment.
I've come up with a slightly better approach.
|
🤖 New build scheduled with the buildbot fleet by @ericsnowcurrently for commit 51d960e 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
| static struct PyModuleDef thread_module; | ||
|
|
||
|
|
||
| /* threads owned by the modulo */ |
|
FTR, I ran the buildbots on commit 51d960e: https://buildbot.python.org/all/#/changes/22637. |
CI run 112 test modules failed before the CI job was canceled. (details)test module timed out after 20 minutes (1200s):
individual tests timed out:
still running:
CI run 212 test modules failed before the CI job was canceled. (details)test module timed out after 20 minutes (1200s):
individual tests timed out:
still running:
Buildbot (ARM64 macOS PR)25 test modules failed (details)test module timed out after 15 minutes (900s):
individual tests timed out:
|
|
I reran the job and got the same result (the tests are not done yet but started to time out already). |
|
This PR is stale because it has been open for 30 days with no activity. |
This should fix the frequent crashes in test_threading and test__xxsubinterpreters.
There is some duplication with the threading module which could be removed after this lands. We can also eliminate
PyThreadState.on_deleteandPyInterpreterState.threads.count, both of which are cases where the state of the threading module leaked out into the runtime.(Also see gh-63008 and gh-18296.)