Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>:
> Changing implementations from one which is thread safe to one which is
> not can break people's code, and shouldn't be done on a whim.
> Especially since such breakage could be subtle, hard to notice, harder
> to track down, and even harder still to fix.
Java's HotSpot does it all the time, and it did result in code
breakage -- although the code was broken to begin with.
> So there is no coherent way to get a result of "impossible" from just
> adding 1 to 1 in any coherent implementation of Python.
Back to Java, there was a real case of 64-bit integer operations not
being atomic on 32-bit machines. Mixing up upper and lower halves
between threads could result in really weird evaluations.
More importantly, this loop may never finish:
# Initially
quit = False
# Thread 1
global quit
while not quit:
time.sleep(1)
# Thread 2
global quit
quit = True
That's the reality in Java and C. I see no reason why that wouldn't be
the reality in Python as well -- unless the language specification said
otherwise.
Marko
PS My example with "impossible" being the result of a racy integer
operation is of course unlikely but could be the outcome if the Python
runtime reorganized its object cache on the fly (in a hypothetical
implementation).
--
https://mail.python.org/mailman/listinfo/python-list
