Thread imbalance

[Ivan Voras]

Peter Hansen wrote:

> Ivan, what makes you say that Python is bad for threads?  Did the 
> qualifcation "concurrently executing/computing" have some significance 
> that I missed?

Because of the GIL (Giant interpreter lock). It can be a matter of 
opinion, but by "good threading implementation" I mean that all threads 
in the application should run "natively" on the underlying (p)threads 
library at all times, without implicit serialization. For example, Java 
and perl do this, possibly also lua and C#. Python and Ruby have a giant 
interpreter lock which prevents two threads of pure python code (not 
"code written in C" :)) ) in one interperter process executing at the 
same time.

Much can be said about "at the same time" part, but at least in one case 
it is unambiguous: in multiprocessor machines. Someone writing a 
multithreaded server application could get in trouble if he doesn't know 
this (of course, it depends on the exact circumstances and the purpose 
of the application; for example system calls which block, such as read() 
and write() can execute concurrently, while two "while True: pass" 
threads cannot). This is not new information, it's available in many 
forms in this newsgroup's archives.

I think it would also make implicit problems in the situation like that 
of the OP, where there's a "watchdog" thread monitoring some job or 
jobs, and the job(s) intefere(s) with the GIL by contenting for it, 
possibly when there are lots of threads or frequent spawning of 
processes or threads.

I don't have the intention to badmouth Python, but to emphasize that one 
should be familira with all the details of the tool one's using :)