As an aside, I really don't think that the case study should be given any more linkjuice as a response to GHC/Haskell IO concurrency questions. While it's a wonderful tutorial on the programming technique side, it'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 connections---a different metric and a different scale.

On Fri, Apr 30, 2010 at 2:51 AM, Don Stewart <dons@galois.com> wrote:

bulat.ziganshin:

> Hello Aran,
>
> Friday, April 30, 2010, 2:26:20 AM, you wrote:
>
> > In GHC, if a thread spawned by forkIO blocks on some network or
> > disk IO, is the threading system smart enough not to wake the thread
>
> afaik, yes. it's controlled by special i/o thread that multiplexes all
> i/o done via stdlibs. but ghc i/o manager can't use epoll/kqueue so
> it's appropriate only for small (or medium?) servers

Look at the recent work on the event library and replacing the IO
manager.

http://www.serpentine.com/blog/2010/01/22/new-ghc-io-manager-first-benchmark-numbers/

There's much more background on the new code here,

http://www.serpentine.com/blog/2009/12/17/making-ghcs-io-manager-more-scalable/

and some nice benchmarks

http://blog.johantibell.com/2010/01/scalable-timeout-support-for-ghcs-io.html