Author cagney
Recipients cagney, ebizzinfotech, gregory.p.smith, hugh, lukasz.langa, ned.deily
Date 2019-04-10.13:45:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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."
Date User Action Args
2019-04-10 13:45:47cagneysetrecipients: + cagney, gregory.p.smith, ned.deily, lukasz.langa, hugh, ebizzinfotech
2019-04-10 13:45:47cagneysetmessageid: <>
2019-04-10 13:45:47cagneylinkissue36533 messages
2019-04-10 13:45:47cagneycreate