<div>Hi Arnar,</div>
<div>&nbsp;</div>
<div>You said, &quot;There have been discussions&nbsp;here occasionally about something generic, like wrapping libevent or&nbsp;similar in an interface that &quot;looks&quot; synchronous but in the background&nbsp;does async I/O and uses channels to make it look synchronous.&quot; That is of course what this does. Points:</div>

<div>&nbsp;- &quot;There have been discussions&quot; implies a blocking point ;-) This is a design that is complete. simple, and proven, and could be put in the virtual machine tomorrow.</div>
<div>&nbsp;- The notion of &quot;asynchronous IO&quot; is vague and, in the typical manner, therefore threatens to&nbsp;complicate matters with&nbsp;a huge palette (your &quot;myriad&quot;)&nbsp;of explicit&nbsp;tools that work at cross-purposes. By contrast, the first phase of this design (Channel Communication plus Hardware Select) would result in&nbsp;NO VISIBLE CHANGE, no libraries - just a clearing of the &quot;blocking&quot; logjam and freedom for other tasklets to run efficiently while the hardware wait is going on, just&nbsp;as David wanted.</div>

<div>&nbsp;-&nbsp;There is also no visible change&nbsp;if you add the second phase,&nbsp;&quot;Timer&quot;: the sleeping tasklet (or simultaneously sleeping tasklets) would take no blocking&nbsp;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?)</div>

<div>&nbsp;- The complication added by these phases&nbsp;is in the virtual machine only: a couple of new queues (channel and timer) in addition to Stackless&#39;s round robin scheduler. The channel queues have maximum length 1. I am assuming that &quot;tasklet&quot; = &quot;process&quot; 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&#39;t imagine anything being &quot;stackless&quot; without that!).</div>

<div>&nbsp;- The only thing that would&nbsp;create a new visible interpreted code option&nbsp;would be the last phase,&nbsp;the user-level ALT or select. And that could be done in any way that people like: for instance, as a standard Unix-like&nbsp;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).</div>

<div>&nbsp;- And all without a myriad: the only other such structure that I&#39;ve ever found useful is a simple binary semaphore (which works just like the timer queue, and avoids the ALT/select overhead in a common case). That could be added later.</div>

<div>&nbsp;- The only question is whether something about the object structure forbids input from several channels in one tasklet.</div>
<div>&nbsp;</div>
<div>Larry<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 10/9/08, <b class="gmail_sendername">Arnar Birgisson</b> &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:arnarbi@gmail.com" target="_blank">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">Hi Larry,<br><br>On Fri, Oct 10, 2008 at 00:54, Larry Dickson &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:ldickson@cuttedge.com" target="_blank">ldickson@cuttedge.com</a>&gt; wrote:<br>
&gt; On Fri, Sep 26 17:09:54 CEST 2008, Arnar Birgisson &lt;arnarbi at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://gmail.com/" target="_blank">gmail.com</a>&gt;<br>&gt;&gt; &gt; Surely there is a way around this?&nbsp;&nbsp;Some kind of pooling select?&nbsp;&nbsp;If<br>
&gt;&gt; &gt; there is<br>&gt;&gt; &gt; no work around then I cannot see too much practical use for my thread<br>&gt;&gt; &gt; library<br>&gt;&gt; &gt; [except having to avoid learning tasklets for someone who is familiar<br>
&gt;&gt; &gt; with<br>&gt;&gt; &gt; threads].&nbsp;&nbsp;As I understand it, due to the GIL the only real practical<br>&gt;&gt; &gt; use for<br>&gt;&gt; &gt; threads is if one has blocking function calls (IO-type, etc)<br>&gt;&gt;<br>
&gt;&gt; The solution would be asynchronous I/O. There have been discussions<br>&gt;&gt; here occasionally about something generic, like wrapping libevent or<br>&gt;&gt; similar in an interface that &quot;looks&quot; synchronous but in the background<br>
&gt;&gt; does async I/O and uses channels to make it look synchronous. I figure<br>&gt;&gt; such a thing would be an excellent component of your thread library.<br>&gt;&gt;<br>&gt;&gt; &gt; [Has the GIL restriction been fixed in 3k?&nbsp;&nbsp;As far as I know Jython does<br>
&gt;&gt; &gt; not<br>&gt;&gt; &gt; have this limitation...]<br>&gt;&gt;<br>&gt;&gt; The GIL has not been removed in Py 3.0, nor will it be removed any<br>&gt;&gt; time soon. Jython does not have such a thing.<br>&gt;<br>&gt; This design solves all these problems, using only C/Unix select (which you<br>
&gt; pointed out is already used to do time.sleep) in the virtual machine; and<br>&gt; it runs in only one thread. There is no need to remove the GIL.<br><br>What problems? If you read my message you can clearly see that I<br>
pointed to a _solution_, namely asynchronous I/O. :) What I meant in<br>my last message is that I don&#39;t see how your suggestion improves on<br>the myriad of async solutions out there already (which are based on<br>select, poll, epoll, Windows ASIO, etc).<br>
<br>cheers,<br>Arnar<br></blockquote></div><br>