[Stackless] Stackless based replacement

Arnar Birgisson arnarbi at gmail.com
Fri Oct 10 17:20:56 CEST 2008

Hey Larry,

On Fri, Oct 10, 2008 at 16:55, Larry Dickson <ldickson at cuttedge.com> wrote:
>  - "There have been discussions" implies a blocking point ;-) This is a
> design that is complete. simple, and proven, and could be put in the virtual
> machine tomorrow.

The blocking point is lack of time only. Libevent or similar can be
(and has been) integrated with Stackless in short time. I even wrote a
simple proof-of-concept of this in one of my messages. Also have a
look at this page for more:

>  - The notion of "asynchronous IO" is vague and, in the typical manner,
> therefore threatens to complicate matters with a huge palette (your
> "myriad") of explicit tools that work at cross-purposes. By contrast, the
> first phase of this design (Channel Communication plus Hardware Select)
> would result in NO VISIBLE CHANGE, no libraries - just a clearing of the
> "blocking" logjam and freedom for other tasklets to run efficiently while
> the hardware wait is going on, just as David wanted.

My point is perhaps that I don't see the need to reinvent the wheel
here, while many async i/o methods exist already.

>  - There is also no visible change if you add the second phase, "Timer": the
> sleeping tasklet (or simultaneously sleeping tasklets) would take no
> blocking time on the round robin. (Your time.sleep code indicates this is
> not currently the case - am I right, or does Py_BEGIN_ALLOW_THREADS set up a
> separate queue?)

That was an entirely different discussion. With "your" timer you are
probably referring to what I copied and pasted here from the Python
source (note, not Stackless, just regular Python) and this was in
relation to testing if one could sleep for less than 2.5 milliseconds.
Of course this sleep(..) is blocking and you cannot use it in a
single-threaded Stackless application. However, the sleep(..) in the
libevent code I also posted works just fine as it is non-blocking,
only made to appear so *at the tasklet level* by using channels.

>  - The complication added by these phases is in the virtual machine only: a
> couple of new queues (channel and timer) in addition to Stackless's round
> robin scheduler. The channel queues have maximum length 1. I am assuming
> that "tasklet" = "process" in the sense I defined in the note (which
> certainly appears to be the case, with the examples you gave). I am also
> assuming there is some memory dedicated to the tasklet for its whole life
> (but I can't imagine anything being "stackless" without that!).

If you can implement asynchronous i/o and timers directly in the
Stackless Python virtual machine that is efficient on all platforms,
just go for it :)

>  - The only thing that would create a new visible interpreted code
> option would be the last phase, the user-level ALT or select. And that could
> be done in any way that people like: for instance, as a standard
> Unix-like select call, or a transputer-like ALT branching on readiness of IO
> channels. In my experience, that is the central key to any serious parallel
> coding (changing disorder into order, as it were).

This could definitely been useful. Some past discussions:

>  - The only question is whether something about the object structure forbids
> input from several channels in one tasklet.

I'm not qualified to answer that - but I would like to be :)


More information about the Stackless mailing list