On 09.02 22:24, Bulat Ziganshin wrote: > as i understand this idea, transformer implementing async i/o should > intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate > async operation, and then switch to another Haskell threads. the I/O > manager thread should run select() in cycle and when the request is > finished, wake up the appropriate thread. what's all. if you will ever > need, this implementation can then be used to extend GHC's System.IO > internals with the support for new async i/o managers (as i > understand, select() is now supported by GHC, but poll(), kqueue() is > not supported?). the only difference that my lib gives an opportunity > to test this implementation without modifying GHC I/O internals, what > is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines > should be the same as for read/write: > > type FD = Int > vGetBuf_async :: FD -> Ptr a -> Int -> IO Int > vPutBuf_async :: FD -> Ptr a -> Int -> IO Int
Please don't fix FD = Int, this is not true on some systems, and when implementing efficient sockets one usually wants to hold more complex state. > JM> Don't take the absence of a feature in jhc to mean I don't like or want > JM> that feature. There are a lot of things I don't have but that I'd > JM> definitly want to see in the language simply because I was only shooting > JM> for H98 to begin with and was more interested in a lot of the back end > JM> stuff. You should figure out the nicest design that uses just the > JM> extensions needed for the design you want. it could help us decide what > JM> goes into haskell-prime to know what is absolutely needed for good > JM> design and what is just nice to have. > > this simply means that the Streams library cannot be used with JHC, > what is bad news, because it is even more rich than GHC's System.IO. > jhc had chance to get modern I/O library. but it lost that chance :) I think it is more like "all haskell-prime programs". Seriously, if we design a new IO subsystem it would be quite nice to be able to use it from standard conforming programs. Maybe things can be reformulated in a way that will be compatible with haskell-prime. > please look. at this moment Sreams library lacks only a few important > features, already implemented in GHC's System.IO: sockets, line > buffering and async i/o. moreover, i don't have an experience in > implementing the async i/o, so foreign help is really necessary If you want I can look at getting network-alt to implement the interface. - Einar Karttunen _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
