3 ms·

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 be

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.

nomel 3y ago
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).
- tomn 3y ago
  I believe that GIL-removal projects aim to preserve this behaviour: https://peps.python.org/pep-0703/#container-thread-safety 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.
- School-Cotton 3y ago
  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).
  - nomel 3y ago
    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.
- miraculixx 3y ago
  The GIL protects interpreter resources, not your program. If you have concurrent access to your own objects you need your own locks.
  - nomel 3y ago
    “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()`.

nomel 3y ago

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

tomn 3y ago
I believe that GIL-removal projects aim to preserve this behaviour: https://peps.python.org/pep-0703/#container-thread-safety 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.
School-Cotton 3y ago
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).
- nomel 3y ago
  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.
miraculixx 3y ago
The GIL protects interpreter resources, not your program. If you have concurrent access to your own objects you need your own locks.
- nomel 3y ago
  “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()`.