3 ms·

ELI5 I get in concept what the GIL is. But what's the impact of this change? Packages will now break, for the hope of better overall performance?

nextaccountic 3y ago
If any package depends on the GIL, it will be enabled. Packages won't break
- hsbauauvhabzb 3y ago
  What packages might depend on the GIL and why would they need it?
  - mlyle 3y ago
    Packages with native components that have not been updated for the semantics changes.
  - whiterknight 3y ago
    Any C code that uses global variables casually.
  - CJefferson 3y ago
    Almost all packages depend on the GIL (at least at first). They assume they can "take the GIL", and then go and look at the various Python datastructures you passed them without worrying about them changing as they are being read. The later, when writing out their answer (which might involve editing something they were given), they can assume they are not changing. For example, you could write code which extends the length of a list to 100, then fill in all the members, not worrying half way through your loop another thread shrinks the list back down.
    - imtringued 3y ago
      This only applies to native extensions.
      - CJefferson 3y ago
        Sorry, you are or course correct, I should have said all extensions with native code.
dathery 3y ago
Previously people basically didn't bother to write multithreaded Python at all due to the GIL. Threads were primarily used when you had multiple pieces of work to do which could end up blocked on independent I/O. Which is common and useful of course, but doesn't help with the performance of CPU-bound Python code. Even outside of high-intensity CPU work, this can be useful. A problem lately is that a lot of code is written using Python's native asyncio language features. These run single-threaded with async/await to yield execution, much like in NodeJS, and can achieve pretty good throughput even with a single thread (thousands of reqs/second). However, a big problem is that any time you do _any_ CPU work, you block all other coroutines, which causes all kinds of obscure issues and ruins your reqs/second. For example, you might see random IO timeouts in one coroutine which are actually caused by a totally different coroutine hogging the CPU for a bit. It can be very hard to get observability into why this is happening. asyncio provides a `asyncio.to_thread()` function [1] which can help to take blocking work off the main thread, but because of the GIL it doesn't truly allow the CPU-bound to avoid interfering with other coroutines. [1] https://docs.python.org/3/library/asyncio-task.html#asyncio.to_thread https://docs.python.org/3/library/asyncio-task.html#asyncio....
- hsbauauvhabzb 3y ago
  Will this also support threads spanning multiple cores, or is that unrelated? Edit: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/ suggests it will support multiple cores, unless the current work does not yet achieve that.
- fireattack 3y ago
  Would GIT affect how Python runs across multiple Python processes? I'm asking because I encountered a weird phenomenon before. I use a simple Python lib called "schedule" which is to run some tasks periodically (not precise). And I often run a script multiple times (with different arguments) to monitor something say, every 30 seconds. So they're in three separate Python Interpreter processes. What I've noticed is that while when I initiated them, they were something like 5 seconds apart, they eventually will end up running in sync. Probably not related to GIL at all, but I guess do no harm to ask.

nextaccountic 3y ago

If any package depends on the GIL, it will be enabled. Packages won't break

hsbauauvhabzb 3y ago
What packages might depend on the GIL and why would they need it?
- mlyle 3y ago
  Packages with native components that have not been updated for the semantics changes.
- whiterknight 3y ago
  Any C code that uses global variables casually.
- CJefferson 3y ago
  Almost all packages depend on the GIL (at least at first). They assume they can "take the GIL", and then go and look at the various Python datastructures you passed them without worrying about them changing as they are being read. The later, when writing out their answer (which might involve editing something they were given), they can assume they are not changing. For example, you could write code which extends the length of a list to 100, then fill in all the members, not worrying half way through your loop another thread shrinks the list back down.
  - imtringued 3y ago
    This only applies to native extensions.
    - CJefferson 3y ago
      Sorry, you are or course correct, I should have said all extensions with native code.

dathery 3y ago

Previously people basically didn't bother to write multithreaded Python at all due to the GIL. Threads were primarily used when you had multiple pieces of work to do which could end up blocked on independent I/O. Which is common and useful of course, but doesn't help with the performance of CPU-bound Python code. Even outside of high-intensity CPU work, this can be useful. A problem lately is that a lot of code is written using Python's native asyncio language features. These run single-threaded with async/await to yield execution, much like in NodeJS, and can achieve pretty good throughput even with a single thread (thousands of reqs/second). However, a big problem is that any time you do _any_ CPU work, you block all other coroutines, which causes all kinds of obscure issues and ruins your reqs/second. For example, you might see random IO timeouts in one coroutine which are actually caused by a totally different coroutine hogging the CPU for a bit. It can be very hard to get observability into why this is happening. asyncio provides a `asyncio.to_thread()` function [1] which can help to take blocking work off the main thread, but because of the GIL it doesn't truly allow the CPU-bound to avoid interfering with other coroutines. [1] https://docs.python.org/3/library/asyncio-task.html#asyncio.to_thread https://docs.python.org/3/library/asyncio-task.html#asyncio....

hsbauauvhabzb 3y ago
Will this also support threads spanning multiple cores, or is that unrelated? Edit: https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/ suggests it will support multiple cores, unless the current work does not yet achieve that.
fireattack 3y ago
Would GIT affect how Python runs across multiple Python processes? I'm asking because I encountered a weird phenomenon before. I use a simple Python lib called "schedule" which is to run some tasks periodically (not precise). And I often run a script multiple times (with different arguments) to monitor something say, every 30 seconds. So they're in three separate Python Interpreter processes. What I've noticed is that while when I initiated them, they were something like 5 seconds apart, they eventually will end up running in sync. Probably not related to GIL at all, but I guess do no harm to ask.