> """
Since the documentation seems to be silent the guarantee (or expectation) is implied - logging systems emit records atomically - if this isn't true across fork() then the exception should be documented.
"""

We can add a note to the docs.  As a general rule: documentation being silent means there are zero guarantees.  Behavior of the existing implementations over time is the only source of truth.


> """
but it didn't address the more fundamental problem:

- when the child enters the code 'b' is undefined

i.e., breaking the lock will allow the child to access data in an undefined state.  This will result in either core dumps or hangs (presumably the motivation for the original change was to prevent this?).
"""

nope.  the contrived emit() pseudocode from msg339650 never defined b in the first place.  that code, if massaged into python syntax would raise an UnboundLocalError no matter who executed it.  a fork() from another thread would not change that.  There is no concept of undefined/uninitialized state from the Python perspective.

The motivation for the original fix was entirely deadlock avoidance in code that uses fork.  It failed and introduced an alternate form of deadlock in code that had been lucky up until that point.  Thus my new PR proposing to fix the regression by making that not fail yet still preventing locks from starting out held in the child process.