On Wed, Feb 22, 2006 at 03:28:26PM +0300, bulat.ziganshin@gmail.com wrote:
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 :)
I think you misunderstand, the poll interface will need to accept a _set_ of events to wait for. This is independent of the buffer interface and lower level than async IO (for the traditional definition of async IO). Not all event sources will necessarily be FDs on unix or handles on windows, if say a haskell RTS integrates with a systems built in event 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.
You can't treat them as independent types at the poll site, since you need to wait on a set of events from potentially different types of 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
I am not quite sure what you mean by this. the poll/select interface will be lower level than your Streams library and fairly independent. The async methods I have seen have been non-blocking based and tend to be system dependent, which is different than what the poll/select interface is about. the poll/select interface is about providing the mininimum functionality to allow _portable_ async applications and libraries to be written. John -- John Meacham - ⑆repetae.net⑆john⑈