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

Johan Tibell johan.tibell at gmail.com
Sat May 1 05:29:05 EDT 2010


Hi Aran,

On Fri, Apr 30, 2010 at 9:28 PM, Aran Donohue <aran.donohue at gmail.com>wrote:

> 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.


The reason was mostly performance concerns due to libev(ent) using callbacks
to signal events. Callbacks from C into Haskell can be inefficient. From the
FFI addendum:

"Optionally, an import declaration can specify, after the calling
convention, the safety level that should be used when invoking an external
entity. A safe call is less efficient, but guarantees to leave the Haskell
system in a state that allows callbacks from the external code."

Another reason was that if the code is in Haskell we can more easily get
people to hack on it and adapt it to our needs.

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.
>

The event library, linked by Don, handles tens of thousands of idle
connections without problems (see the idle connection generator [1] I
created). Bryan wrote a simple HTTP server [2] that handles 20,000 requests
per second on one core.

1. http://github.com/tibbe/event/blob/master/benchmarks/DeadConn.hs
2. http://github.com/tibbe/event/blob/master/benchmarks/StaticHttp.hs

Cheers,
Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100501/c8d374de/attachment.html


More information about the Haskell-Cafe mailing list