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

Johann Höchtl writes:

I think the overall goal should be to get rid of http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hs..., 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