Hacker News Reader

Comment by zackees | Hacker News Reader

I agree with this take.

The GIL is hiding all kinds of concurrency bugs. If the CPython team default disable it then all hell is going to break loose.

It's better to carve out special concurrency constructs for those that need it.

View on HN

Not sure why this was flagged dead. If you look at many stackoverflow answers, around threading, many explicitly rely on the GIL, quoting source/documentation “proving” that it’s safe, avoiding the use of threading.Lock() and the like.

As an early python programmer, I copy pasted these types of answers. My old threaded code absolutely has these bugs. I’ve even seen code in production that has these bugs, because they’re sometimes dumb performance enhancements, rather than bugs, unless you happen to use a Python interpreter without a GIL, especially one that that doesn’t exist yet.

Great care would have to be taken to make sure the GIL was not disabled by default, for anything an existing thread touches (or some super, dynamic aware, smarts to know if it can be disabled).

I believe that GIL-removal projects aim to preserve this behaviour:

https://peps.python.org/pep-0703/#container-thread-safety

That's why gilectomy carries an unreasonable single-threaded performance cost: many operations now need to take a lock where before they relied on the GIL.

Why do you consider code that relies on the GIL to be buggy? Isn't the GIL a documented, stable part of Python? (Hence why it will probably never be removed).

5th sentence in my comment:

> I’ve even seen code in production that has these bugs, because they’re sometimes dumb performance enhancements, rather than bugs, unless you happen to use a Python interpreter without a GIL, especially one that that doesn’t exist yet.

The GIL protects interpreter resources, not your program. If you have concurrent access to your own objects you need your own locks.

“Interpreter resources” are just python primitives, from the user perspective. And, from that perspective, you can sometimes get away without using user managed locks, by relying on the GIL, in your objects. For example, you can trivially use a list as a multi threaded queue, using `.append()` and `.pop()`.

Reply on news.ycombinator.com