Hello Einar, Friday, February 10, 2006, 2:09:08 AM, you wrote:
as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate
type FD = Int vGetBuf_async :: FD -> Ptr a -> Int -> IO Int vPutBuf_async :: FD -> Ptr a -> Int -> IO Int
EK> Please don't fix FD = Int, this is not true on some systems, EK> and when implementing efficient sockets one usually wants EK> to hold more complex state. the heart of the library is class Stream. both "File" and "Socket" should implement this interface. just now i use plain "FD" to represent files, but that is temporary solution - really file also must carry additional information: filename, open mode, open/closed state. This "File" will be an abstract datatype, what can be based not on FD in other operating systems. The same applies to the "Socket". it can be any type what carry enough information to work with network i/o. implementation of async i/o should have a form of Stream Transformer, which intercepts only the vGetBuf/vPutBuf operations and pass other operations as is: data AsyncFD = AsyncFD FD ... {-additional fields-} instance Stream IO AsyncFD where vIsEOF (AsyncFD h ...) = vIsEOF h vClose (AsyncFD h ...) = vClose h ........ vGetBuf (AsyncFD h ...) ptr size = vGetBuf_async h ptr size as far as i see, the select/epoll don't need to know anything about file/socket except for its descriptor(FD) ? in this case we can make the Async transformer universal, compatible with both files and sockets: data Async h = Async h ... {-additional fields-} addAsyncIO h = do ..... return (Async h ...) instance (Stream IO h) => Stream IO (Async h) where vIsEOF (Async h ...) = vIsEOF h vClose (Async h ...) = vClose h ........ vGetBuf (Async h ...) ptr size = doBlockingOp "read" h $ vGetBuf h ptr size this transformer can be made universal, supporting select/epoll/... implementations via additional parameter to the "addAsyncIO", or it can be a series of transformers, one for each method of async i/o. if we have developed common API for async i/o as John suggested, then one universal transformer working via this API can be used
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 :)
EK> I think it is more like "all haskell-prime programs". Seriously, EK> if we design a new IO subsystem it would be quite nice to be EK> able to use it from standard conforming programs. EK> Maybe things can be reformulated in a way that will be compatible EK> with haskell-prime. or haskell-prime can be reformulated ;) as h' will be defined in first iteration, i will check my lib and say to comittee what i will need to omit from my library to be compatible with this standard. then we can decide :) just at current moment, support for complex class hierrachies outside of Hugs/GHC is very poor
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
EK> If you want I can look at getting network-alt to implement the EK> interface. please look. basically, Sock should be made an instance of Stream with implementations of vGetBuf/vPutBuf and other operations, as much as possible. it should be easy, see the FD/Handle instances of Stream for example and your support of select/poll should go into the tranformer(s). this will allow to use async i/o not only for your own Sock type, but for files, for the sockets from the old library and so on -- Best regards, Bulat mailto:bulatz@HotPOP.com