3 ms·

I would argue the GIL is a feature put in place to make it easier to write parallel code. If you want to do this in a more performant way you should be looking

I would argue the GIL is a feature put in place to make it easier to write parallel code. If you want to do this in a more performant way you should be looking at a different language. People talk about the GIL as if it’s just some drawback that could be removed and everything would be faster. There is a very good reason why it’s there.

masklinn 7y ago
> I would argue the GIL is a feature put in place to make it easier to write parallel code. It doesn't do that though. The GIL protects interpreter internals. It doesn't make Python code thread-safe, although it does make various operations atomic: * native calls (which doesn't release the GIL) * individual bytecode instructions (which don't call into more python code) The latter can make it seem like it magically protects your code, but even a simple method call is at least 3 instructions (LOAD_FAST, LOAD_METHOD and CALL_METHOD). Each instruction is atomic and the method call will be if it's a native call (e.g. dict.get) but that's it, the entire call itself is not atomic and you could thread-switch between LOAD_FAST and LOAD_METHOD, or LOAD_METHOD and CALL_METHOD.
- dickeytk 7y ago
  You just explained a bunch of implementation details but at the end of the day my point remains: having the GIL makes it easier to write parallel code. I didn't say it magically makes everything threadsafe.
  - masklinn 7y ago
    > having the GIL makes it easier to write parallel code. It does not. What it does is create a bigger trap, because the code looks to be working in more testing situations, and will be more difficult to debug when it starts failing.
pavanky 7y ago
Isnt the GIL part of the implementation rather than the language?
- dickeytk 7y ago
  In the same exact way the garbage collector is. You never touch it but the fact it's there makes it easier to write code.
laurencerowe 7y ago
Assuming you mean concurrent rather than parallel as the GIL prevents you from running Python code in parallel. How does the GIL make things easier compared to the finer grained locking found in Jython which allows parallel execution of Python code in threads? Threads may still be switched between instructions every sys.setswitchinterval milliseconds so every instruction boundary is still a potential thread switch point, leading to all the issues described by Glyph in his Unyielding essay: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html

masklinn 7y ago

> I would argue the GIL is a feature put in place to make it easier to write parallel code. It doesn't do that though. The GIL protects interpreter internals. It doesn't make Python code thread-safe, although it does make various operations atomic: * native calls (which doesn't release the GIL) * individual bytecode instructions (which don't call into more python code) The latter can make it seem like it magically protects your code, but even a simple method call is at least 3 instructions (LOAD_FAST, LOAD_METHOD and CALL_METHOD). Each instruction is atomic and the method call will be if it's a native call (e.g. dict.get) but that's it, the entire call itself is not atomic and you could thread-switch between LOAD_FAST and LOAD_METHOD, or LOAD_METHOD and CALL_METHOD.

dickeytk 7y ago
You just explained a bunch of implementation details but at the end of the day my point remains: having the GIL makes it easier to write parallel code. I didn't say it magically makes everything threadsafe.
- masklinn 7y ago
  > having the GIL makes it easier to write parallel code. It does not. What it does is create a bigger trap, because the code looks to be working in more testing situations, and will be more difficult to debug when it starts failing.

pavanky 7y ago

Isnt the GIL part of the implementation rather than the language?

dickeytk 7y ago
In the same exact way the garbage collector is. You never touch it but the fact it's there makes it easier to write code.

laurencerowe 7y ago

Assuming you mean concurrent rather than parallel as the GIL prevents you from running Python code in parallel. How does the GIL make things easier compared to the finer grained locking found in Jython which allows parallel execution of Python code in threads? Threads may still be switched between instructions every sys.setswitchinterval milliseconds so every instruction boundary is still a potential thread switch point, leading to all the issues described by Glyph in his Unyielding essay: https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html