[Haskell-cafe] Re: standard poll/select interface

[bulat.ziganshin at gmail.com]

Hello John,

Wednesday, February 22, 2006, 3:32:34 AM, you wrote:

>> I agree that a generic select/poll interface would be nice.  If it was
>> in terms of Handles though, that's not useful for implementing the I/O 
>> library.  If it was in terms of FDs, that's not portable - we'd need a 
>> separate one for Windows.  How would you design it?

JM> Yeah, this is why I have held off on a specific design until we get a
JM> better idea of what the new IO library will look like. I am thinking it
JM> will have to involve some abstract event source type with primitive
JM> routines for creating this type from things like handles,fds, or
JM> anything else we might want to wait on. so it is system-extendable in
JM> that sense in that implementations can just provide new event source
JM> creation primitives.

i don't think that we need some fixed interface. it can be just
parameterized:

type ReadBuf  h = h -> Ptr () -> Int -> IO Int
type WriteBuf h = h -> Ptr () -> Int -> IO ()

so Unix implementations will use FD, Windows implementation will work
with Handle and all will be happy :)

JM> The other advantage of this sort of thing is that you would want things
JM> like the X11 library to be able to provide an event source for when an
JM> X11 event is ready to be read so you can seamlessly integrate your X11
JM> loop into your main one.

you don't need to have the same interface for the X11 and files async
operations. The library can export "ReadBuf FD", "WriteBuf FD" and
"X11Op" implementations and you will use each one in appropriate
place.

JM> The X11 library would create such an event source from the underlying
JM> socket but just return the abstract event source so the implementation
JM> can change (perhaps when using a shared memory based system like D11 for
JM> instance) without affecting how the user uses the library in a portable
JM> way.

JM> I will try to come up with something concrete for us to look at that we
JM> can modify as the rest of the IO library congeals.

as i already said, this IO library will not emerge by itself :)  there
is my library which use Stream class so it can accept any form of
async library. there is a lib by Marcin Kowalczyk. and there is
Einar's Alt-Network lib which already implements 2 async methods. so
what we need is to convert Einar's work to single interface and make a
Stream interface around this. the later will be better accomplished by
me, but i don't know whether he planned to work on former. i can also
do it, but without any testing because i still don't have any Unix
installed :)  Streams library by itself is now unix-compilable, thanks
to Peter Simons

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com