Having worked with multi-threaded applications in other languages, I'm starting to think that the GIL is more a good thing than a bad thing.
Seriously, threads are evil.
back
1 comments
The GIL does not make threads less evil than you apparently already find them, it just makes them a lot less useful.
Threads in Python still have all the pitfalls and complications they have in other languages, it's just that they cannot use multiple cores or hardware threads. So you get all the evil bits (race conditions, deadlocks, having to protect access to shared state, etc), but you miss out on all the performance benefits threads can have on parallel hardware.
In Python, threads are only useful as an abstraction of things that have to run concurrently, even though they never do.
Not that I want to distract of your righteous rant, but threads also work without issues when doing mostly IO: C libraries and implementations are free to release the GIL (and often do). So if you want to e.g. fetch a bunch of things concurrently, those will be done concurrently. And your
> have to run concurrently, even though they never do.
is way off base.
Likewise, if you're doing CPU-heavy crunching (likely implemented in C or Cython), you can release the GIL and let the interpreter run some other bytecode at the same time.
> In Python, threads are only useful as an abstraction of things that have to run concurrently, even though they never do.
This is just false. Threads still offer performance benefits for non-CPU bound operations. For example, if you are trying to download data from 100 different sources, you could do it in a single thread, but python would spend most of its time idling while other prosseses do work, or you could have 100 threads, so python can do work while it is waiting on other stuff to get done.