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