[Stackless] Stackless based replacement

Larry Dickson ldickson at cuttedge.com
Fri Oct 3 00:06:52 CEST 2008


Hi Arnar and David,

I'm new to the mailing list, and am not sure it is working for me, so I'm
sending this to your apparent email addresses too.

If I'm following you right, asynchronous IO is not needed. All that is
needed is a loop on a non-blocking select (or, to avoid busyness, a select
against the IO and one tick later than the last time noted by the loop). If
you can put code into the virtual machine, it can be even cleaner: an
unconditional swap out of the tasklet; whenever its turn comes up in the
round robin, an unblocking select on its IO; and whenever all tasklets are
waiting on IO, a blocking select on all outstanding IO.

By dealing with the selects alone, you can emulate the occam ALT primitive
which says "swap out until any of this list come ready." Old Inmos
documentation shows how to get the state machine exactly right for that,
including timers.

Larry Dickson
Cutting Edge Networked Storage

On Fri, Sep 26 17:09:54 CEST 2008, Arnar Birgisson <arnarbi at gmail.com>
wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20081002/fff2b111/attachment.htm>


More information about the Stackless mailing list