global interpreter lock not working as it should

[Armin Steinhoff]

anton wilson <anton.wilson at camotion.com> wrote in message news:<mailman.1027984856.20250.python-list at python.org>...
> 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. 
> 
> However, this problem is solved by placing a explicit sched_yield between the 
> calls to release the lock and to acquire the lock again in the interpreter 
> loop. Then, switching works perfectly. 
> 
> What is the problem here? 

The 'problem' is that Python threads are not fully comparable with
system level threads. Python threads are managed (scheduled) at
_interpreter level_!!

The important difference is that Python threads can't use e.g.
blocking I/O calls ... a blocking I/O call used in a Python thread
will block the whole interprete!!.

Real threading is only possible if each Python thread whould be
handled by an own instance of the interpreter which is running in its
own system thread.
(This is possible with Lua ...) 


Armin



>Any thoughts would be appreciated.
> 
> 
> Anton