> 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.

Wow!  It is pseudo code, right? (I figured using Ada like attributes was a bit of a giveaway).  Nitpicking it achieves nothing (if you feel that your language needs 'b' pre-defined then, hey!, pre-define it; I'm pretty sure that won't fix the problem of operations such b[i] = 2 not being atomic yet alone thread-safe in Python).

Lets instead focus on my point that breaking the locks won't fix the problem.  For instance, above.  Or "For instance, if the fork() happens while a thread is holding the <stdio.h> FILE lock on a log file, then the child trying to access that FILE will hang."