[Stackless] Mixing os threads and stackless

Lloyd Weehuizen lloyd at fusion.net.nz
Thu Apr 27 00:52:21 CEST 2006

>>>> I don't *think* you'd get much advantage with this as the python 
>>>> global interpreter lock will block all threads while another is 
>>>> executing so you might as well run a single thread with all your 
>>>> tasklets in it?
>>> Why would the PGIL block all threads?
>> Correct me if I'm wrong but afaik the PGIL only allows one thread to be 
>> executing python code ( or C code called from python that hasn't 
>> explicitly released the PGIL ) at any one time?
> What does "at one time" mean?
This is my understanding of the situation...

Given two threads, python byte code cannot be run on Thread B while 
Thread A is executing. Thread A will have to release the GIL before 
Thread B can obtain the GIL and enter the kernels run queue... So you're 
adding a context switch that doesn't give you much advantage, unless 
Thread A is going to go away for a decent amount of time ( database 
call, sleep, or other blocking C functions that release the GIL ) 
without wanting the GIL again.

Python does release the GIL every 100? byte code instructions, so your 
threads will run "concurrently". But as you add more CPUs to your system 
you won't see any increase in concurrency as you're still limited to one 
thread executing byte code at any one time.

You will get minimal advantage ( if any ? and you add unnecessary 
context switching overhead ) if you're running mainly python byte code 
without calling into C functions that release the GIL for decent periods 
of time.

Generally I think its easier to run your python code on a single thread, 
with C code starting additional threads for blocking tasks and wrapping 
your Python/C transition points in stackless channels.

For example if you're talking to a database,  your python code calls 
ExecuteQuery ( a C function ) which sends a request to your C database 
thread to start the query and then blocks ( the main thread ) on a 
stackless channel. Stackless then switches your tasklet out and runs 
other tasklets until your database thread has its results at which point 
it sends the result down your stackless channel which puts your calling 
tasklet back in the stackless run queue. ( Stackless may need the GIL to 
do the final send down the channel, i'm not sure, but thats a very small 
execution time )

This gives a clean interface from the python side, without the python 
code having to know anything about threads.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list