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).
Ok. I' 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 this efficient? 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.
Ok, thanks. In GHC there is only one IO manager thread? And forkIO can execute code in a separate OS thread, if necessary?
Cheers, Simon
Regards Manlio