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 :) -- http://mail.python.org/mailman/listinfo/python-list