Why does python's threading library use OS level threads when it can't achieve parallelism?

Question

I was surprised to hear that the threading module from python uses OS level threads. From what I know, OS level threads are more expensive (but can achieve parallelism) meanwhile green threads are user-level, more lightweight, but can only achieve concurrency but not parallelism. Why doesn't the python virtual machine implement a scheduler for user-level threads and replace the threading module OS threads?

If the GIL restricts the number of threads running at once then there is effectively no benefit (other than simplicity of implementation on python's side) to having OS level threads over user level threads, right?

Answer 1

Green threads are ancient stuff and the references you are reading are probably citing reasons that mostly don't apply today. It is more complex than you write, with software engineering and performance tradeoffs that are hard to summarize in just a few sentences, but here is a rough overview:

OS level threads allow taking advantage of multiple cores or multiple processors, which are common today.

Green threads incur an overhead to keep track of the thread states and swap between them. If you only have a limited number of threads, the OS is just as good at that or better.

Green threads handle blocking system calls poorly.

Green threads only have the potential to be better if the number of active threads is significantly more than the number of cores/processors. That is not the case for most applications today; for most applications, the number of threads is fewer than the number of cores. Even if it true, there is no guarantee that green threads will be faster; that depends on other factors.

Answer 2

It's not necessarily true that green threads cannot achieve parallelism. Just check out the runtimes for Go, Elixir, and Clojure - they're doing just fine.

While the actual reason as to why Python didn't go for this route is unclear, if I had to guess: it's probably because green threads don't play nice with C.

Python has a closer relation to C than most languages that have their reference implementations written in C. You'll find that many Python primitives map directly to the underlying C implementation. Interfacing with C code from Python already has many costs, having green threads just means appending the extra cost of context switches to that list. So, it should make sense that Python uses OS threads, because C does the same.

Python has many target audiences. While web developers might benefit from getting the same experience in Python as they get in a language like Go, something like this might've broken the scientific community's heart in other, unexpected ways.

That said, the future looks promising in 2022: CPython is getting rid of the GIL, and Python has a better WASM story than most people expected. I'm not sure where my stance will be in the future, but for now, I'd probably use a better language for the job.