[email protected]
[Top] [All Lists]

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

Subject: Re: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?
From: Johann HÃchtl
Date: Fri, 11 Dec 2009 19:39:44 +0100
Gregory Collins wrote:
Johann HÃchtl <[email protected]> writes:

I think the overall goal should be to get rid of
http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc,
as it's in the core.
I don't follow, could you explain?


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 ;)
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>
BTW: Here are also some names and ideas mentioned:
http://www.haskell.org/pipermail/cvs-ghc/2008-February/041236.html

I actually had web applications in mind when I asked my first question as many tiny and lightweight requests to the web server will become more and more the rule with techniques as comet or Bayeux protocoll or HTML5 web sockets. I speculate this will be even more true with per thread garbage collection in GHC 6.12.x
Any non-blocking call to select should be save to replace by epoll, as the
semantics are the same.
Not exactly the same; but keep in mind we also need to support kqueue &
Windows I/O completion ports (and select() as a fallback). In an ideal
world you can provide a unified API that will work across all of the
platforms, with the I/O multiplexer hidden behind the interface.


Absolutely right, I forgot to mention. I am aware of

epoll - Linux
kqueue - the BSD's and MacOS; does the interface differ, on MacOS, I dont't know IO Completion Port <http://msdn.microsoft.com/en-us/library/aa365198%28VS.85%29.aspx> - Windows (http://stackoverflow.com/questions/67082/what-is-the-best-epoll-kqueue-select-equvalient-on-windows)
poll - Solaris

As epoll is considerably more fine grained than non-blocking select,
the architecture must support a run loop which effectively retrieves
events faster than non-blocking select would do. Otherwise the effort
would be futile.
It'd be hard to be slower, with select() you have to do O(n) "fdIsSet"
tests.

G
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

<Prev in Thread] Current Thread [Next in Thread>