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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
