<br><br>
<div><span class="gmail_quote">On 10/10/08, <b class="gmail_sendername">Arnar Birgisson</b> &lt;<a href="mailto:arnarbi@gmail.com">arnarbi@gmail.com</a>&gt; 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 &lt;<a href="mailto:ldickson@cuttedge.com">ldickson@cuttedge.com</a>&gt; wrote:<br>
&gt;&nbsp;&nbsp;- &quot;There have been discussions&quot; implies a blocking point ;-) This is a<br>&gt; design that is complete. simple, and proven, and could be put in the virtual<br>&gt; 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>&nbsp;&nbsp;<a href="http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules">http://code.google.com/p/stacklessexamples/wiki/StacklessNonblockModules</a></blockquote>

<div>&nbsp;</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">&gt;&nbsp;&nbsp;- The notion of &quot;asynchronous IO&quot; is vague and, in the typical manner,<br>&gt; therefore threatens to complicate matters with a huge palette (your<br>
&gt; &quot;myriad&quot;) of explicit tools that work at cross-purposes. By contrast, the<br>&gt; first phase of this design (Channel Communication plus Hardware Select)<br>&gt; would result in NO VISIBLE CHANGE, no libraries - just a clearing of the<br>
&gt; &quot;blocking&quot; logjam and freedom for other tasklets to run efficiently while<br>&gt; the hardware wait is going on, just as David wanted.<br><br>My point is perhaps that I don&#39;t see the need to reinvent the wheel<br>
here, while many async i/o methods exist already.</blockquote>
<div>&nbsp;</div>
<div>My point is that there doesn&#39;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">&gt;&nbsp;&nbsp;- There is also no visible change if you add the second phase, &quot;Timer&quot;: the<br>&gt; sleeping tasklet (or simultaneously sleeping tasklets) would take no<br>
&gt; blocking time on the round robin. (Your time.sleep code indicates this is<br>&gt; not currently the case - am I right, or does Py_BEGIN_ALLOW_THREADS set up a<br>&gt; separate queue?)<br><br>That was an entirely different discussion. With &quot;your&quot; 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>&nbsp;</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">&gt;&nbsp;&nbsp;- The complication added by these phases is in the virtual machine only: a<br>&gt; couple of new queues (channel and timer) in addition to Stackless&#39;s round<br>
&gt; robin scheduler. The channel queues have maximum length 1. I am assuming<br>&gt; that &quot;tasklet&quot; = &quot;process&quot; in the sense I defined in the note (which<br>&gt; certainly appears to be the case, with the examples you gave). I am also<br>
&gt; assuming there is some memory dedicated to the tasklet for its whole life<br>&gt; (but I can&#39;t imagine anything being &quot;stackless&quot; 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>&nbsp;</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">&gt;&nbsp;&nbsp;- The only thing that would create a new visible interpreted code<br>&gt; option would be the last phase, the user-level ALT or select. And that could<br>
&gt; be done in any way that people like: for instance, as a standard<br>&gt; Unix-like select call, or a transputer-like ALT branching on readiness of IO<br>&gt; channels. In my experience, that is the central key to any serious parallel<br>
&gt; 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>&nbsp;</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)&nbsp;a case statement?</div>
<div>&nbsp;</div>
<div>Larry</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt;&nbsp;&nbsp;- The only question is whether something about the object structure forbids<br>&gt; input from several channels in one tasklet.<br>
<br>I&#39;m not qualified to answer that - but I would like to be :)<br><br>cheers,<br>Arnar<br></blockquote></div><br>