1. 9

  2. 8

    As a quick refresher because it isn’t fully explained in the article: the precise restriction of Python’s GIL is that only one thread can be executing Python byteocde and/or accessing the interpreter’s C API at any given time.

    This is a historical tradeoff dating to when most things people wanted threading for were going to be I/O-bound and running on the single-processor/single-core hardware of the era, which did not foresee the CPU-bound tasks and multi-processor/multi-core hardware that are common now. The popular numeric/scientific libraries for Python get around this by being Python wrappers around fast implementations of the mathematical stuff written in C/C++/Fortran/etc. and by releasing the GIL whenever they have a bunch of number-crunching to do that doesn’t require access to bytecode or the interpreter API, which means they can do multithreaded CPU-bound workloads more efficiently.