4 ms·
wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code? I think there is a valid argument to keeping the GI
by Areading314 4y ago
wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code? I think there is a valid argument to keeping the GIL just for simplicity's sake
- bratao 4y agoFrom 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?