3 ms·
From my understanding, race conditions already exists today as the GIL is made to protect the internal Python structures. It only made it appears more infrequen
by bratao 4y ago
From my understanding, race conditions already exists today as the GIL is made to protect the internal Python structures. It only made it appears more infrequently.
- masklinn 4y ago> It only made it appears more infrequently. It makes some operations atomic which is quite relevant.
- MrJohz 4y agoFewer 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?