First, thanks for all your support :)<br><br>I don&#39;t understand why the implementation forces me to use channels, if I do not need to &#39;transfer&#39; data. You use the channel as a semaphore. I would think that it is better to implement semaphore, and then implement channels based on semaphores. Of course, it makes sense for coroutines exchanging data, but there is cases where no data need to be transfered. Of course, by semaphore, I mean semaphores working with the Áthreads, not necessarily the ones of the kernel. I implemented the latter a while ago in C#.<br>
<br>I guess I should compare combinations of asyncore, twisted, stackless&#39; scheduler, and custom scheduler using continuations provided by stackless.<br><br>(On a side note, it is scaring that so few languages support continuations)<br>
<br>Laurent.<br><br><div class="gmail_quote">On Feb 13, 2008 2:44 PM, Arnar Birgisson &lt;<a href="mailto:arnarbi@gmail.com">arnarbi@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Laurent,<br><div class="Ih2E3d"><br>On Feb 13, 2008 10:23 AM, Laurent Debacker &lt;<a href="mailto:debackerl@gmail.com">debackerl@gmail.com</a>&gt; wrote:<br>&gt; Is it possible to schedule microthreads based on event? For example, let&#39;s<br>
&gt; suppose that a Áthread writes data through a socket. The write will block<br>&gt; the Áthread, but is asynchronous for the real thread. Consequently, the<br>&gt; async write is started, the scheduler is called, and the Áthread is put on a<br>
&gt; waiting list until its write is completed. In addition, the scheduler shall<br>&gt; never call back a Áthread that is still blocked, and the stackless.run() may<br>&gt; not return while there is still blocking Áthreads.<br>
<br></div>In general you do this by having the create a channel, store it<br>somewhere and read from it. This will block the Áthread. When the<br>event happens, the event dispatching code writes to the channel which<br>wakes up the Áthread.<br>
<div class="Ih2E3d"><br>&gt; I have looked at the wsgi server sample, but the performance become so poor<br>&gt; on windows when the number of concurrent connection increases. In addition,<br>&gt; there is that strange asyncore_loop function with the pool call which scares<br>
&gt; me.<br><br></div>The current WSGI server uses the asyncore module from the std. Python<br>library. It&#39;s performance is certainly not optimal. I think someone<br>was working (or had already completed) a WSGI server based on<br>
libevent&#39;s http module, something I&#39;ve been meaning to do myself but<br>time escapes me. Let&#39;s hope the person in question speaks up.<br><div class="Ih2E3d"><br>&gt; What I want, is a WSGI server, with one thread per CPU/core, and one Áthread<br>
&gt; per connection :)<br><br></div>If you wrote a WSGI middleware that dispatched requests to multiple<br>underlying WSGI servers (in your case one for each CPU/core) and<br>&quot;fixed&quot; the performance problems for the current WSGI server on<br>
stacklessexamples you should be in business.<br><br>cheers,<br><font color="#888888">Arnar<br></font></blockquote></div><br>