<div>Hi Arnar and David,</div>
<div>&nbsp;</div>
<div>I&#39;m new to the mailing list, and am not sure it is working for me, so I&#39;m sending this to your apparent email addresses too.</div>
<div>&nbsp;</div>
<div>If I&#39;m following you right, asynchronous IO is not needed. All that is needed is a loop on a non-blocking select (or, to avoid busyness, a select against the IO and one tick later than the last time noted by the loop). If you can put&nbsp;code into the virtual machine, it can be even cleaner: an unconditional swap out of the tasklet; whenever its turn comes up in the round robin, an unblocking select on its IO; and whenever all tasklets are waiting on IO, a blocking select on all outstanding IO.</div>

<div>&nbsp;</div>
<div>By dealing with the selects alone, you can emulate the occam ALT primitive which says &quot;swap out until any of this list&nbsp;come ready.&quot; Old Inmos documentation shows how to get the state machine exactly right for that, including timers.</div>

<div>&nbsp;</div>
<div>Larry Dickson</div>
<div>Cutting Edge Networked Storage</div>
<div>&nbsp;</div>
<div>On Fri, Sep 26 17:09:54 CEST 2008, Arnar Birgisson &lt;arnarbi at <a href="http://gmail.com">gmail.com</a>&gt; wrote:<br>&gt; Hey there,<br>&gt;<br>&gt; On Fri, Sep 26, 2008 at 15:50, David Naylor &lt;dragonsa at <a href="http://highveldmail.co.za">highveldmail.co.za</a>&gt; wrote:<br>
&gt; &gt;&gt; &gt; 2) Will stackless switch to another tasklet when entering blocking<br>&gt; &gt;&gt; &gt; routines<br>&gt; &gt;&gt; &gt; (like IO), I know threads do this...<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; No it won&#39;t.&nbsp; In fact, it fundamentally *can&#39;t* (since it &quot;runs&quot; in<br>
&gt; &gt;&gt; only one thread).<br>&gt; &gt;<br>&gt; &gt; Surely there is a way around this?&nbsp; Some kind of pooling select?&nbsp; If there is<br>&gt; &gt; no work around then I cannot see too much practical use for my thread library<br>
&gt; &gt; [except having to avoid learning tasklets for someone who is familiar with<br>&gt; &gt; threads].&nbsp; As I understand it, due to the GIL the only real practical use for<br>&gt; &gt; threads is if one has blocking function calls (IO-type, etc)<br>
&gt;<br>&gt; The solution would be asynchronous I/O. There have been discussions<br>&gt; here occasionally about something generic, like wrapping libevent or<br>&gt; similar in an interface that &quot;looks&quot; synchronous but in the background<br>
&gt; does async I/O and uses channels to make it look synchronous. I figure<br>&gt; such a thing would be an excellent component of your thread library.<br>&gt;<br>&gt; &gt; [Has the GIL restriction been fixed in 3k?&nbsp; As far as I know Jython does not<br>
&gt; &gt; have this limitation...]<br>&gt;<br>&gt; The GIL has not been removed in Py 3.0, nor will it be removed any<br>&gt; time soon. Jython does not have such a thing.<br>&gt;<br>&gt; &gt;&gt; &gt; 3) Does anyone know where to find how many commands python processes<br>
&gt; &gt;&gt; &gt; before it<br>&gt; &gt;&gt; &gt; tries to switch threads (I remember something like that happening?)<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; It&#39;s not really &quot;commands&quot;... more like a number of loops through the<br>
&gt; &gt;&gt; code interpreter.<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; Did you mean &quot;threads&quot; or &quot;tasklets&quot;?<br>&gt; &gt;<br>&gt; &gt; Threads<br>&gt;<br>&gt; The Python interpreter loop is basically one big case expression that<br>
&gt; reads the bytecodes and performs the corresponding actions. At the top<br>&gt; of this loop there is a check that is the equivalent of:<br>&gt;<br>&gt; _Py_Ticker -= 1<br>&gt; if _Py_Ticker &lt; 0:<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; _Py_Ticker = _Py_CheckInterval<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; release the GIL<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; aquire the GIL<br>&gt;<br>&gt; Just between the last two lines, other threads have the oppurtunity to<br>&gt; run. _Py_CheckInterval is currently set at 100. This means this GIL<br>&gt; release+aquire (plus other maintenance stuff) is done *at most* every<br>
&gt; 100 opcodes. However, since some opcodes use &quot;fast jumping&quot;, i.e.<br>&gt; instead of going through the interpreter loop again, they jump<br>&gt; directly to another opcode in the case statement and _Py_Ticker is not<br>
&gt; decreased. This means that there might be more than 100 opcodes<br>&gt; interpreted between releasing the GIL.<br>&gt;<br>&gt; You can view the code in question here:<br>&gt; <a href="http://svn.python.org/view/python/trunk/Python/ceval.c?rev=65241&amp;view=auto">http://svn.python.org/view/python/trunk/Python/ceval.c?rev=65241&amp;view=auto</a><br>
&gt;<br>&gt; cheers,<br>&gt; Arnar<br>&nbsp;</div>