Thanks for the explanations. This sounds like an interesting path.

> Each thread implementation (thread_pthread.h, thread_nt.h)
> would provide a new PyThread_reinit_lock function that would do the
> right thing (pthread_mutex_destroy/init, sem_destroy/init, etc).
> Modules/threadmodule.c would provide a new PyThread_ReInitLocks that
> would walk through the linked list and call PyThread_reinit_lock for
> each lock.

Actually, I think the issue is POSIX-specific: Windows has no fork(),
and we don't care about other platforms anymore (they are, are being, or
will be soon deprecated).
It means only the POSIX implementation needs to register its locks in a
linked list.

> But this wouldn't allow a lock's state to be inherited across fork for
> the main thread (but like I said, I don't think that this makes much
> sense anyway, and to my knowledge no implementation makes such a
> guarantee - and definitely not POSIX).

Well, the big difference between Python locks and POSIX mutexes is that
Python locks can be released from another thread. They're a kind of
trivial semaphore really, and this makes them usable for other purpose
than mutual exclusion (you can e.g. use a lock as a simple event by
blocking on a second acquire() until another thread calls release()).

But even though we might not be "fixing" arbitrary Python code
automatically, fixing the interpreter's internal locks (especially the
IO locks) would be great already.

(we could also imagine that the creator of the lock decides whether it
should get reinitialized after fork)