[Stackless] Stackless based replacement
ldickson at cuttedge.com
Fri Oct 10 18:48:57 CEST 2008
On 10/10/08, Arnar Birgisson <arnarbi at gmail.com> wrote:
> Hey Larry,
> On Fri, Oct 10, 2008 at 16:55, Larry Dickson <ldickson at cuttedge.com>
> > - "There have been discussions" implies a blocking point ;-) This is a
> > design that is complete. simple, and proven, and could be put in the
> > 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:
These address the same problem, but shift to module variants what is
actually a virtual machine issue. What happens if different tasklets use
different modules in the same run?
> - 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.
My point is that there doesn't need to be a wheel at all. No change in
> - There is also no visible change if you add the second phase, "Timer":
> > 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.
Can two tasklets use the libevent code and have their sleep periods overlap?
> - The complication added by these phases is in the virtual machine only:
> > 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 :)
Where is the C source for the virtual machine?
> - 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
> > 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
> > channels. In my experience, that is the central key to any serious
> > coding (changing disorder into order, as it were).
> This could definitely been useful. Some past discussions:
What is preferred, do you think: a call and explicit check on the lines of
select, or a syntax thing that would act like (or maybe even be) a case
> - The only question is whether something about the object structure
> > input from several channels in one tasklet.
> I'm not qualified to answer that - but I would like to be :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless