On Thu, Jan 1, 2009 at 8:32 PM, Bryan O'Sullivan wrote:

On Wed, Dec 31, 2008 at 11:42 AM, Levi Greenspan wrote:

...

Hence my question - is it likely that GHC will support epoll in 2009?

Yes. I'm working on a patch at the moment.

Awesome! Please post to this list when you have any news or updates. Thanks, Bit

On Thu, Dec 10, 2009 at 5:01 AM, Johann Höchtl wrote:

...

Yes. I'm working on a patch at the moment.

Is there something planed to happen in 2010?

Retooling the I/O manager isn't a huge job, but it requires the equivalent of several weeks of work. I tossed out my initial attempt at a patch because I didn't have time to work on it, so I'm back to square one. Johan Tibell and I have had occasional discussions about picking up the thread again, but we've had a busy year and it's moderately demanding work, so nothing has actually happened. If I develop the time and energy to take a serious crack at it, I will post here to let people know. This would be an effort where having multiple people work on different implementations concurrently would be a shame.

On 10/12/2009 17:48, Bryan O'Sullivan wrote:

On Thu, Dec 10, 2009 at 5:01 AM, Johann Höchtl mailto:johann.hoechtl@gmail.com> wrote:

> Yes. I'm working on a patch at the moment.

Is there something planed to happen in 2010?

Retooling the I/O manager isn't a huge job, but it requires the equivalent of several weeks of work. I tossed out my initial attempt at a patch because I didn't have time to work on it, so I'm back to square one. Johan Tibell and I have had occasional discussions about picking up the thread again, but we've had a busy year and it's moderately demanding work, so nothing has actually happened.

If I develop the time and energy to take a serious crack at it, I will post here to let people know. This would be an effort where having multiple people work on different implementations concurrently would be a shame.

Bryan, if you have time could you give a brief outline of the main sticking points? My gut feeling is that it shouldn't be "several weeks of work", but admittedly I've never worked with epoll(). Perhaps we need to take a step back and think about the architecture at a higher level? Cheers, Simon

Gregory Collins wrote:

"Bryan O'Sullivan" writes:

...

If I develop the time and energy to take a serious crack at it, I will post here to let people know. This would be an effort where having multiple people work on different implementations concurrently would be a shame.

I'm interested in this topic as well and have recently starting hacking timeout support into Johan's event library:

http://github.com/tibbe/event http://github.com/gregorycollins/event

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. Any non-blocking call to select should be save to replace by epoll, as the semantics are the same. 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.

Maybe we should form a working group?

G

Gregory Collins wrote:

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?

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