[Haskell-cafe] Re: Climbing up the shootout...
manlio_perillo at libero.it
Mon Sep 29 18:01:33 EDT 2008
Simon Marlow ha scritto:
> Manlio Perillo wrote:
>> Simon Marlow ha scritto:
>>> Manlio Perillo wrote:
>>> 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.
>> There is some documentation that summarize the current status, and how
>> all fits together?
> Sadly no, but the code is mostly restricted to a couple of modules
> (GHC.Handle and GHC.Conc).
I'm also reading the "unify" paper.
What I would like to do is to write a library for high efficient IO,
using the code from Nginx (that is well written and reusable).
What Nginx give us is:
1) Several modules for efficient event handling on all platform.
There is also Windows support with IOCP, but the code is not public
(but lately someone is porting Nginx to Windows, and I can always ask
the author of Nginx to make his code public).
2) Support for SSL.
3) There is support for timeouts, using a red black tree.
In Haskell timeouts are handled spwawing a thread with forkIO, but is
4) Support for async DNS resolver.
5) Support for "sending" buffer chains.
A buffer chain is "sent" with writev.
In Haskell a ByteString has several chunks, so it can be efficiently
"sent" using writev.
6) Support for file buffers.
A file buffer is "sent" with sendfile, if available.
There is no equivalent in Haskell.
Since I have started to work with Nginx, I had the interest of reusing
the Nginx code as a library/framework, but all the languages I knew did
not have native support for microthreads (Python has greenlets, but it
also already hase Twisted, so it is of little interest to implement yet
another async framework).
GHC seems the best platform to use, since it has microthreads, and
Haskell language allow a "safe" use of OS threads.
>> There are some benchmarks that tell you the use of a separate I/O
>> manager thread is a good solution?
> Compared to what? I did measure the difference between doing this in
> Haskell code in the IO library (as with -threaded) against doing it in
> the RTS (without -threaded),
Yes, this is what I meant.
> and the Haskell version won hands down,
> mainly because it only re-initiates the select() when it has to change
> the file handles in the set. Using epoll() instead of select() should
> be even better.
In GHC there is only one IO manager thread?
And forkIO can execute code in a separate OS thread, if necessary?
More information about the Haskell-Cafe