Bryan Donlan wrote: > As such, initially I'd like to focus my efforts on generalizing the > infastructure to support more than one IO manager per platform, and > implementing epoll as an initial test.
This would be great to have, but you might be overlapping with work that Peng Li has been planning for a while: http://www.seas.upenn.edu/~lipeng/homepage/ I don't know if his thesis proposal has been approved; at least some of it rings my "baseless handwaving" alarm bells. You might want to check with him and the Simons to see what the GHC HQ plans are here. > My initial plan was to break up the mingw and select() based event > loops, and place each into its own module (GHC.IOMgr.Select etc). Each > would have an initialization function (init :: IO IOMgr) to either > initialize the IO manager, or break and toss an exception; the > GHC.IOMgr module would then have a list of supported IO managers and > try each in turn. This allows us to fall back from epoll to select > when GHC is built against a libc with epoll, but run on an old kernel > which does not support epoll; it also paves the way for other IO > managers in the future (kqueue, libev, etc...) Your rationale (falling back to select if epoll not present) will not work in practice, so I would not suggest making this as a basis for providing multiple per-platform IO managers. While it would clearly make sense to have a common API that a given platform's event manager (epoll, WaitForMultipleObjects, etc) would support, I think you should find a strong argument for providing more than one manager for a given platform. <b _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
