
Bulat Ziganshin wrote:
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:
I don't think async I/O is a stream transformer, fitting it into the stream hierarchy seems artificial to me. It is just another way of doing I/O directly to/from file descriptors. If your basic operation to read from an FD is readFD :: FD -> Int -> Ptr Word8 -> IO Int then an async I/O layer simply provides you with the exact same interface, but with an implementation that doesn't block other threads. It is part of the file descriptor interface, not a stream transformer. Also, you probably need readNonBlockingFD :: FD -> Int -> Ptr Word8 -> IO Int isReadyFD :: FD -> IO Bool in fact, I think this should be the basic API, since you can implement readFD in terms of it. (readNonBlockingFD always reads at least one byte, blocking until some data is available). This is used to partially fill an input buffer with the available data, for example. One problem here is that in order to implement readNonBlockingFD on Unix you have to put the FD into O_NONBLOCK mode, which due to misdesign of the Unix API affects other users of the same file descriptor, including other programs. GHC suffers from this problem. Cheers, Simon