[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