> However, extending RLock to provide ForkClearedRLock (this would be used by logging, i.e.) is quite straighforward.
>
> The extended class would simply need to record the process ID, in which the lock was created, and the process ID, which is trying to acquire it.  Done!

There are at least two problems with this approach.
- with LinuxThreads, threads have different PIDs, so this would break.
 LinuxThreads have now been replaced with NPTL, so this may not be a
showstopper, though
- however, the other problem is more serious: it has the exact same
problem as the lock reinitialization upon fork(): locks are used to
protect critical sections, to make sure that threads see a consistent
state: if you simply proceed and reset/acquire the lock when the
process is not the last one that owned it, the invariants protected by
the lock will be broken.
The proper solution is to setup handlers to be called upon fork, that
not only reset locks, but also internal state of objects they protect.
However, this is a dull and boring task, and would require patching
dozens of different places. It's been on my todo list for some time...
Another "solution" would be to remove the only place in the standard
library where a bare fork() is used, in multiprocessing (issue #8713).
Then, it's the user's problem if he calls fork() :-)