[Haskell-cafe] are forkIO threads event-driven?

[Aran Donohue]

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 <dons at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100430/a29fa98b/attachment.html