4 ms·
Fewer than people expect. For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't
by MrJohz 4y ago
Fewer than people expect. For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here.
- masklinn 4y ago> For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here. Sure, but any call to a native function which doesn’t release the gil (which is most of them at least for the builtins) is currently atomic so something like dict.setdefault.
- masklinn 4y agoAnd note that this is mentioned in the faq.
- dontlaugh 4y agoThose would have to remain atomic by taking explicit more granular locks.
- masklinn 4y agoObviously? But the point is currently they do work, they are thread-safe and they are correct in the strictest sense of the word, per-FAQ: https://docs.python.org/3/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe https://docs.python.org/3/faq/library.html#what-kinds-of-glo... So as the original commenter notes: > wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code?