[Stackless] [threading] Stackless based replacement

Arnar Birgisson arnarbi at gmail.com
Fri Sep 26 17:09:54 CEST 2008


Hey there,

On Fri, Sep 26, 2008 at 15:50, David Naylor <dragonsa at highveldmail.co.za> wrote:
>> > 2) Will stackless switch to another tasklet when entering blocking
>> > routines
>> > (like IO), I know threads do this...
>>
>> No it won't.  In fact, it fundamentally *can't* (since it "runs" in
>> only one thread).
>
> Surely there is a way around this?  Some kind of pooling select?  If there is
> no work around then I cannot see too much practical use for my thread library
> [except having to avoid learning tasklets for someone who is familiar with
> threads].  As I understand it, due to the GIL the only real practical use for
> threads is if one has blocking function calls (IO-type, etc)

The solution would be asynchronous I/O. There have been discussions
here occasionally about something generic, like wrapping libevent or
similar in an interface that "looks" synchronous but in the background
does async I/O and uses channels to make it look synchronous. I figure
such a thing would be an excellent component of your thread library.

> [Has the GIL restriction been fixed in 3k?  As far as I know Jython does not
> have this limitation...]

The GIL has not been removed in Py 3.0, nor will it be removed any
time soon. Jython does not have such a thing.

>> > 3) Does anyone know where to find how many commands python processes
>> > before it
>> > tries to switch threads (I remember something like that happening?)
>>
>> It's not really "commands"... more like a number of loops through the
>> code interpreter.
>>
>> Did you mean "threads" or "tasklets"?
>
> Threads

The Python interpreter loop is basically one big case expression that
reads the bytecodes and performs the corresponding actions. At the top
of this loop there is a check that is the equivalent of:

_Py_Ticker -= 1
if _Py_Ticker < 0:
    _Py_Ticker = _Py_CheckInterval
    release the GIL
    aquire the GIL

Just between the last two lines, other threads have the oppurtunity to
run. _Py_CheckInterval is currently set at 100. This means this GIL
release+aquire (plus other maintenance stuff) is done *at most* every
100 opcodes. However, since some opcodes use "fast jumping", i.e.
instead of going through the interpreter loop again, they jump
directly to another opcode in the case statement and _Py_Ticker is not
decreased. This means that there might be more than 100 opcodes
interpreted between releasing the GIL.

You can view the code in question here:
http://svn.python.org/view/python/trunk/Python/ceval.c?rev=65241&view=auto

cheers,
Arnar




More information about the Stackless mailing list