We could make any later attempt to acquire or release a lock that was reinitialized while it was held raise an exception.

Such exception raising behavior should be conditional at lock construction time; some code (such as logging) never wants to deal with one because it is unacceptable for it to ever fail or deadlock.  It should also be possible for the exception to be usefully handled if caught; locks should gain an API to clear their internal "reinitialized while held" flag.

Q: Should .release() raise the exception?  Or just warn?  I'm thinking no exception on release().  Releasing a lock that was held during re-initialization could just reset the "reinitialized while held" flag.

The acquire() that would deadlock or crash today would be where raising an exception makes the most sense.

Deadlocks are unacceptable.  The whole point of this bug is that we can do better.  An exception would provide a stack trace of exactly which thing where caused the offending operation so that the code can be fixed to not misuse locks in the first place or that specific lock can be changed to silent reinitialization on fork.  (or better yet, the fork can be removed entirely)

Both behaviors are better than today.  This change would surface bugs in people's code much better than difficult to debug deadlocks.

It should be a pretty straightforward change to reinit_locks_2 (Patch Set 6) to behave that way.

Looking back, raising an exception is pretty much what I suggested in http://bugs.python.org/issue6721#msg94115 2.5 years ago.