This draft PR currently only modifyPython/thread_pthread.h. I leftPython/thread_nt.h unchanged.

_PyThread_at_fork_reinit() is still implemented by allocating a new lock and leaking the old lock.

@colesbury: What do you think of this idea? Does it make sense? Do you see any possible issue?

If the approach makes sense, I will update my PR to modify also the Windows implementation.

I think the idea is fine, but the PR title and description are confusing.threading.Lock /_thread.lock /_thread._thread.allocate_lock() already usePyMutex (all three are the same thing):

This PR changes the implementation of the C APIPyThread_allocate_lock(). We are generally usingPyMutex directly instead ofPyThread_allocate_lock() in new code, and we've also changed a lot of existing uses too. UsingPyMutex directly is simpler because it avoids an allocation that may fail.

I think it's okay to change the implementation ofPyThread_allocate_lock(). It looks like it's going to simplify the code, but there's some risk of unknown behavioral changes.