[Haskell-cafe] standard poll/select interface

[Einar Karttunen]

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