[Haskell-cafe] standard poll/select interface

[Bulat Ziganshin]

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 at HotPOP.com