[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:

    http://darcs.haskell.org/libraries/base/GHC/Conc.lhs

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/2.2.1.5/doc/html/Network-Socket.html>Network.Socket.Internal
> and in the IO monad when it comes to
> files. <http://hackage.haskell.org/packages/archive/network/2.2.1.5/doc/html/Network-Socket-Internal.html>
> 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/2.2.1.5/doc/html/Network-Socket-Internal.html>
> 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/2.2.1.5/doc/html/Network-Socket-Internal.html>

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

G
-- 
Gregory Collins <greg at gregorycollins.net>


More information about the Haskell-Cafe mailing list