Thanks for the excellent links, that&#39;s exactly what I wanted. It&#39;s interesting that they&#39;ve chosen not to base the new work on libevent. <div><br></div><div>As an aside, I really don&#39;t think that the case study should be given any more linkjuice as a response to GHC/Haskell IO concurrency questions. While it&#39;s a wonderful tutorial on the programming technique side, it&#39;s a decade old and was written at a time when serving 4000 requests was a reasonable benchmark. These days modern web servers are moving more and more toward handling tens of thousands of concurrent held-open <i>connections</i>---a different metric and a different scale.</div>
<div><br></div><div>Cheers,</div><div>Aran<br><br></div><div><br></div><div><br><div class="gmail_quote">On Fri, Apr 30, 2010 at 2:51 AM, Don Stewart <span dir="ltr">&lt;<a href="mailto:dons@galois.com">dons@galois.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">bulat.ziganshin:<br>
<div class="im">&gt; Hello Aran,<br>
&gt;<br>
&gt; Friday, April 30, 2010, 2:26:20 AM, you wrote:<br>
&gt;<br>
&gt; &gt; In GHC, if a thread spawned by forkIO blocks on some network or<br>
&gt; &gt; disk IO, is the threading system smart enough not to wake the thread<br>
&gt;<br>
&gt; afaik, yes. it&#39;s controlled by special i/o thread that multiplexes all<br>
&gt; i/o done via stdlibs. but ghc i/o manager can&#39;t use epoll/kqueue so<br>
&gt; it&#39;s appropriate only for small (or medium?) servers<br>
<br>
</div>Look at the recent work on the event library and replacing the IO<br>
manager.<br>
<br>
    <a href="http://www.serpentine.com/blog/2010/01/22/new-ghc-io-manager-first-benchmark-numbers/" target="_blank">http://www.serpentine.com/blog/2010/01/22/new-ghc-io-manager-first-benchmark-numbers/</a><br>
<br>
There&#39;s much more background on the new code here,<br>
<br>
    <a href="http://www.serpentine.com/blog/2009/12/17/making-ghcs-io-manager-more-scalable/" target="_blank">http://www.serpentine.com/blog/2009/12/17/making-ghcs-io-manager-more-scalable/</a><br>
<br>
and some nice benchmarks<br>
<br>
    <a href="http://blog.johantibell.com/2010/01/scalable-timeout-support-for-ghcs-io.html" target="_blank">http://blog.johantibell.com/2010/01/scalable-timeout-support-for-ghcs-io.html</a><br>
</blockquote></div><br></div>