[Haskell-cafe] New IO foundations. [Was: Climbing up the shootout...]

[Don Stewart]

simonmarhaskell:
> Manlio Perillo wrote:
> >Don Stewart ha scritto:
> >>[...]
> >>Ok. So I'll just say: high level, efficient code is an overriding theme
> >>of many individuals working on Haskell. Things are better and better
> >>each year. We do not stand still.
> >>
> >
> >Any roadmap for improve support in intensive IO multiplexing?
> >Or, at least, some papers about how this is implemented in GHC?
> >
> >Af far as I understand, select is used in two separate places.
> >How much effort it takes to implement a pluggable "reactor" (select, 
> >poll, epoll, kqueue, /dev/poll, and so)?
> 
> We'd certainly support any efforts to add support for a more modern I/O 
> multiplexing or asynchronous I/O back-end to the IO library.  It's not 
> too difficult, because the interface between the low-level I/O supplier 
> and the rest of the IO library is rather small - just a few functions 
> that read and write blocks of data in a blocking or non-blocking way. 
> The blocking variants currently communicate with the I/O manager thread 
> which does select() on behalf of the clients.
> 

Indeed, it has been done at least once elsewhere,

    http://www.seas.upenn.edu/~lipeng/homepage/unify.html

Check the tarball for a custom bytestring and epoll implementation used
to scale up to 10M haskell threads,

    http://www.seas.upenn.edu/%7Elipeng/unify/unify-0.0.1.tar.gz

Perhaps something worth resuscitating code for, for more epoll servers.

-- Don