[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.
Lloyd
_______________________________________________
Stackless mailing list
Stackless at stackless.com
http://www.stackless.com/mailman/listinfo/stackless
More information about the Stackless
mailing list