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 <[email protected]> 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 >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
