Bug report

Bug description:

A forked process (via os.fork) can inherit a locked runtime->interpreters.mutex from its parent process and will deadlock in this stack:
Child Process (deadlocked):
#0 0x0000ffffa9b2b268 in do_futex_wait.constprop () from /lib/aarch64-linux-gnu/libpthread.so.0
#1 0x0000ffffa9b2b39c in __new_sem_wait_slow.constprop.0 () from /lib/aarch64-linux-gnu/libpthread.so.0
#2 0x0000ffffa9e96eb8 in PyThread_acquire_lock_timed () from /usr/local/lib/libpython3.8.so.1.0
#3 0x0000ffffa9e865a8 in _PyThreadState_DeleteExcept () from /usr/local/lib/libpython3.8.so.1.0
#4 0x0000ffffa9eb94ac in PyOS_AfterFork_Child () from /usr/local/lib/libpython3.8.so.1.0

Similar to #74580 and it's solved by f82c951 on python3.6 and 3.7

However,the problem appeares again on python3.8: HEAD_LOCK is called from PyOS_AfterFork_Child->_PyEval_ReInitThreads->_PyThreadState_DeleteExcept before PyOS_AfterFork_Child->_PyRuntimeState_ReInitThreads reinit runtime->interpreters.mutex.

I notice the problem will be resolved on python3.12 from the source code,but is it still existed on python3.8 to 3.11?

CPython versions tested on:

3.8

Operating systems tested on:

Linux

Linked PRs

• [3.11]GH-112275: Fix HEAD_LOCK deadlock in child process after fork #112336
• [3.10] gh-112275: Fix HEAD_LOCK deadlock in child process after fork (GH-112336) #123687
• [3.9] gh-112275: Fix HEAD_LOCK deadlock in child process after fork (GH-112336) #123688
• [3.8] gh-112275: Fix HEAD_LOCK deadlock in child process after fork (GH-112336) (GH-123688) #123713