Thanks for the excellent links, that's exactly what I wanted. It's
interesting that they've chosen not to base the new work on libevent.
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.
Cheers,
Aran
On Fri, Apr 30, 2010 at 2:51 AM, Don Stewart
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...
There's much more background on the new code here,
http://www.serpentine.com/blog/2009/12/17/making-ghcs-io-manager-more-scalab...
and some nice benchmarks
http://blog.johantibell.com/2010/01/scalable-timeout-support-for-ghcs-io.htm...