[Stackless] [threading] Stackless based replacement
arnarbi at gmail.com
Fri Sep 26 17:09:54 CEST 2008
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"?
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:
More information about the Stackless