On Tue, 21 Feb 2006, John Meacham wrote:
Yeah, this is why I have held off on a specific design until we get a better idea of what the new IO library will look like. I am thinking it will have to involve some abstract event source type with primitive routines for creating this type from things like handles,fds, or anything else we might want to wait on. so it is system-extendable in that sense in that implementations can just provide new event source creation primitives.
The other advantage of this sort of thing is that you would want things like the X11 library to be able to provide an event source for when an X11 event is ready to be read so you can seamlessly integrate your X11 loop into your main one.
The X11 library would create such an event source from the underlying socket but just return the abstract event source so the implementation can change (perhaps when using a shared memory based system like D11 for instance) without affecting how the user uses the library in a portable way.
Could an application reasonably choose between several dispatching systems? For example, I'm working on a Macintosh here, where instead of X11 Apple provides its NextStep based GUI with its own apparently fairly well defined event system. I don't know that system very well, but a MacOS Haskell GUI application would probably want to look in that direction for event integration. Meanwhile, I might want to work with kqueue, on the same platform, because it supports filesystem events along with the usual select stuff. Donn Cave, donn@drizzle.com