cagney <andrew.cag...@gmail.com> added the comment:
> 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." ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36533> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
