<br><br>
<div><span class="gmail_quote">On 10/10/08, <b class="gmail_sendername">Arnar Birgisson</b> <<a href="mailto:arnarbi@gmail.com">arnarbi@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hey Larry,<br><br>On Fri, Oct 10, 2008 at 16:55, Larry Dickson <<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>> wrote:<br>
> - "There have been discussions" implies a blocking point ;-) This is a<br>> design that is complete. simple, and proven, and could be put in the virtual<br>> machine tomorrow.<br><br>The blocking point is lack of time only. Libevent or similar can be<br>
(and has been) integrated with Stackless in short time. I even wrote a<br>simple proof-of-concept of this in one of my messages. Also have a<br>look at this page for more:<br> <a href="http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules">http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules</a></blockquote>
<div> </div>
<div>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?</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - The notion of "asynchronous IO" is vague and, in the typical manner,<br>> therefore threatens to complicate matters with a huge palette (your<br>
> "myriad") of explicit tools that work at cross-purposes. By contrast, the<br>> first phase of this design (Channel Communication plus Hardware Select)<br>> would result in NO VISIBLE CHANGE, no libraries - just a clearing of the<br>
> "blocking" logjam and freedom for other tasklets to run efficiently while<br>> the hardware wait is going on, just as David wanted.<br><br>My point is perhaps that I don't see the need to reinvent the wheel<br>
here, while many async i/o methods exist already.</blockquote>
<div> </div>
<div>My point is that there doesn't need to be a wheel at all. No change in source code.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - There is also no visible change if you add the second phase, "Timer": the<br>> sleeping tasklet (or simultaneously sleeping tasklets) would take no<br>
> blocking time on the round robin. (Your time.sleep code indicates this is<br>> not currently the case - am I right, or does Py_BEGIN_ALLOW_THREADS set up a<br>> separate queue?)<br><br>That was an entirely different discussion. With "your" timer you are<br>
probably referring to what I copied and pasted here from the Python<br>source (note, not Stackless, just regular Python) and this was in<br>relation to testing if one could sleep for less than 2.5 milliseconds.<br>Of course this sleep(..) is blocking and you cannot use it in a<br>
single-threaded Stackless application. However, the sleep(..) in the<br>libevent code I also posted works just fine as it is non-blocking,<br>only made to appear so *at the tasklet level* by using channels.</blockquote>
<div> </div>
<div>Can two tasklets use the libevent code and have their sleep periods overlap?</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - The complication added by these phases is in the virtual machine only: a<br>> couple of new queues (channel and timer) in addition to Stackless's round<br>
> robin scheduler. The channel queues have maximum length 1. I am assuming<br>> that "tasklet" = "process" in the sense I defined in the note (which<br>> certainly appears to be the case, with the examples you gave). I am also<br>
> assuming there is some memory dedicated to the tasklet for its whole life<br>> (but I can't imagine anything being "stackless" without that!).<br><br>If you can implement asynchronous i/o and timers directly in the<br>
Stackless Python virtual machine that is efficient on all platforms,<br>just go for it :)</blockquote>
<div> </div>
<div>Where is the C source for the virtual machine?</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - The only thing that would create a new visible interpreted code<br>> option would be the last phase, the user-level ALT or select. And that could<br>
> be done in any way that people like: for instance, as a standard<br>> Unix-like select call, or a transputer-like ALT branching on readiness of IO<br>> channels. In my experience, that is the central key to any serious parallel<br>
> coding (changing disorder into order, as it were).<br><br>This could definitely been useful. Some past discussions:<br><a href="http://www.stackless.com/pipermail/stackless/2007-September/003019.html">http://www.stackless.com/pipermail/stackless/2007-September/003019.html</a><br>
<a href="http://www.stackless.com/pipermail/stackless/2004-January/002580.html">http://www.stackless.com/pipermail/stackless/2004-January/002580.html</a><br><a href="http://www.stackless.com/pipermail/stackless/2002-August/000994.html">http://www.stackless.com/pipermail/stackless/2002-August/000994.html</a></blockquote>
<div> </div>
<div>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?</div>
<div> </div>
<div>Larry</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> - The only question is whether something about the object structure forbids<br>> input from several channels in one tasklet.<br>
<br>I'm not qualified to answer that - but I would like to be :)<br><br>cheers,<br>Arnar<br></blockquote></div><br>