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

Gregory Collins greg at gregorycollins.net
Fri Dec 11 12:14:32 EST 2009


Johann Höchtl <johann.hoechtl at gmail.com> 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?


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


> 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
-- 
Gregory Collins <greg at gregorycollins.net>


More information about the Haskell-Cafe mailing list