[Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?

Gregory Collins greg at gregorycollins.net
Fri Dec 11 14:08:22 EST 2009

Johann Höchtl <johann.hoechtl at gmail.com> writes:

> I might be wrong, but it's EPoll.hsc where you define the call to the Linux
> kernel function. This would be unneccessary, when poll (and kqueue and Windows
> equivalents) are already in the core. Ok, a bit more than EPoll.hsc would be
> unneccessary ;)

Not sure what you mean by "core"; see for instance the code for GHC's
current I/O manager:


There's no special magic going on there, select() and friends are bound
using the normal FFI mechanism.

> What I mean is that applications like web servers should benefit immediately
> from a change in the exisiting core and not require a (new) library. So a
> change is likely neccessary in Network.Socket and
> <http://hackage.haskell.org/packages/archive/network/>Network.Socket.Internal
> and in the IO monad when it comes to
> files. <http://hackage.haskell.org/packages/archive/network/>
> If someone want's to benefit from more functionality, like overlapping IO on
> Windows, the extension may be platform dependent
> available. <http://hackage.haskell.org/packages/archive/network/>
> However, in order to produce portable code which uses non blocking IO "the new
> way", a programer should never have to think about the target
> platform. <http://hackage.haskell.org/packages/archive/network/>

Yes, of course. The idea would (or might) be to fold the event library
into GHC directly and rewrite the I/O manager in terms of it. Many (if
not all) of the library I/O functions may have to be adapted to work
with a new I/O manager. By writing it as a library first we can

  a) write programs that use I/O multiplexing before support gets into
     GHC core proper

  b) ensure that the mechanisms are well tested and benchmarked before
     they are integrated into GHC

Gregory Collins <greg at gregorycollins.net>

More information about the Haskell-Cafe mailing list