[Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?
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
> 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"
Gregory Collins <greg at gregorycollins.net>
More information about the Haskell-Cafe