global interpreter lock not working as it should

[brueckd at tbye.com]

On Tue, 30 Jul 2002, Jonathan Hogg wrote:

> I think the main problem is that you're trying to do something with Python
> threads that they just weren't designed for: CPU intensive work.
> 
> Even if you "fix" Python to force a re-schedule, the GIL means you still
> only have one thread executing at a time and get NO CONCURRENCY.

When you get right down to it, there's really *little* difference between 
Python threads and C threads, so the above statement doesn't make too much 
sense to me. Sure the GIL makes sure that Python object internals are 
fiddled with one thread at a time, but if you have only 1 CPU, there's 
only one thread running at a time anyway, regardless of whether your 
program is in C or Python. IOW, the GIL has no real effect on the 
applicability or usefulness of threads (assuming a single CPU).

> Python threads just aren't any good for parallelism.

Remove the word 'Python' and your statement is more correct. Threads 
themselves aren't all that good for parallelism, which is fine because 
that's not what they're for anyway. If you're doing CPU-intensive work on 
a single CPU, making the program multithreaded (regardless of language 
used) has a good chance of slowing the program down.

> They're mainly useful as a communication abstraction.

Sorry, but that's just plain wrong. Python threads are useful for the 
exact same things threads are useful for in Java, C, etc. (handling 
multiple blocking tasks simultaneously, doing "stuff" while waiting for 
user input, etc.).

> You can browse the archives of this group for many (many) discussions on
> "fixing" the GIL, but you aren't going to get a solution.

That discussion typically revolves around multi-CPU systems, but the OP
didn't mention having multiple CPUs.

-Dave