global interpreter lock not working as it should

[Aahz]

In article <mailman.1027984856.20250.python-list at python.org>,
anton wilson  <anton.wilson at camotion.com> wrote:
>
>I'm running linux 2.4.18 and 2.4.19 with Python 2.2 and the linuxthreads 
>library. 
>
>I'm having a problem where the interpreter in ceval.c does not let     
>threads run concurently. Any thread that holds the lock never gives    
>up the lock until it has run to completion. In addition to my program  
>printouts I've tested and found that as long as a thread needs to run, 
>it will always reaquire the GIL immediately after releasing it every   
>10 byte codes! Of course, if a thread never blocks on the GIL, no      
>other thread will ever run. And this is what is happening.             

If you're using pure Python code, yes this often happens, depending on
what OS you're using.  However, there's nothing wrong with it, either:
if you're writing threaded applications, you should be making zero
assumptions about the order in which threads execute unless you use
locks to force synchronization.

If you want threads to run concurrently, truly concurrently, you'll need
to make function calls to extensions that release the GIL.  That
basically means either I/O calls (and time.sleep() is an I/O call) or
extensions that you write yourself.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Project Vote Smart: http://www.vote-smart.org/