> > Is there any particular reason not to merge Charles-François's reinit_locks.diff?
> > 
> > Reinitialising all locks to unlocked after a fork seems the only sane option.
>
> I agree with this. 
> I haven't looked at the patch very closely. I think perhaps each lock
> could have an optional callback for specific code to be run after
> forking, but that may come in another patch.
> (this would allow to make e.g. the C RLock fork-safe)

An alternative way of handling RLock.acquire() would be to always start by trying a non-blocking acquire while holding the GIL: if this succeeds and self->rlock_count != 0 then we can assume that the lock was cleared by PyThread_ReinitLocks().