Re:Grumpy: Go running Python
by earthboundkid on Wednesday January 04, 2017 @11:12PM
(#13324672)
That's not a good characterization of the GIL. It doesn't prevent races or make multithreaded mylist.append safe. It makes sure that mylist.append doesn't cause a segfault as the bytes in RAM are in an inconsistent state during an update. Beyond that, it doesn't really protect you from your bad threaded code.
[ Parent
| on HN ]
(assuming mylist is a standard python list) it does prevent races inside mylist.append. It does make mylist.append safe.
When I wrote "append from two threads .. as expected" I meant "two items will be added, which one first is unspecified", and the GIL certainly takes care of that.
I agree it does not protect you from your bad threaded code - but then, nothing short of STM does (and even STM doesn't guarantee starvation in the general sense - nothing can).
An unintended side effect of the GIL is that all calls to a C implemented function are atomic and single threaded, provided that the C function doesn't release the GIL. In practice this means lists and dicts are thread safe and existing Python code relies on this.