On 10/10/08, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > > Hey Larry, > > On Fri, Oct 10, 2008 at 16:55, Larry Dickson <[EMAIL PROTECTED]> > 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: > http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules
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 source code. > - 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. 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: > 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 :) 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 > 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: > http://www.stackless.com/pipermail/stackless/2007-September/003019.html > http://www.stackless.com/pipermail/stackless/2004-January/002580.html > http://www.stackless.com/pipermail/stackless/2002-August/000994.html 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 statement? Larry > - 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 :) > > cheers, > Arnar >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
