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

[Bulat Ziganshin]

Hello John,

Wednesday, February 22, 2006, 5:11:04 PM, you wrote:

it seems that we don't understand each other. let's be concrete:

my library reads and writes files. it uses read/write/recv/send to do
this in blocking manner. now i want to have another operations what will
have the SAME INTERFACES but internally use something like poll in
order to allow Haskell RTS support i/o overlapping with "user
threads". agree? 

these async operations should had the same interface as blocked ones,
but that is impossible for Windows, so i propose to had slightly more
general interfaces:

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

these are functions which my library will call, all other drom my
viewpoint are internal details of this async lib. i don't know (i really
don't know) how to build this list of events and how to manage it.

the same is for X11 library - async lib just should provide alternative
implementation of some operations and don't require from the user of
async lib to manage eventlist.

it seems like you want to define something more low-level, but i'm as
i/o library author will be happy just to call some non-blocking
equivalents of read/write provided by async lib. and it seems that i'm
not competent enough to discuss details of its internal implementation
;)

on the other side, you don't need to wait while some i/o library will
be make standard. anyway such library will need non-blocking
implementations of read() and write(), so this is the high-level
interface that async lib should implement. agree?


>> 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> I think you misunderstand, the poll interface will need to accept a
JM> _set_ of events to wait for. This is independent of the buffer interface
JM> and lower level than async IO (for the traditional definition of async
JM> IO). Not all event sources will necessarily be FDs on unix or handles on
JM> windows, if say a haskell RTS integrates with a systems built in event
JM> loop (such as the OSX example mentioned in another email).


>> 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> You can't treat them as independent types at the poll site, since you
JM> need to wait on a set of events from potentially different types of
JM> sources.

>> 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

JM> I am not quite sure what you mean by this. the poll/select interface
JM> will be lower level than your Streams library and fairly independent.
JM> The async methods I have seen have been non-blocking based and tend to
JM> be system dependent, which is different than what the poll/select
JM> interface is about. the poll/select interface is about providing the
JM> mininimum functionality to allow _portable_ async applications and
JM> libraries to be written. 

JM>         John




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