Hacker News Reader

Comment by Areading314 | Hacker News Reader

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

View on HN

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.

> It only made it appears more infrequently.

It makes some operations atomic which is quite relevant.

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.

> 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.

And note that this is mentioned in the faq.

Those would have to remain atomic by taking explicit more granular locks.

Obviously?

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-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?

Reply on news.ycombinator.com