On Fri, Feb 15, 2008 at 2:13 PM, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote: > 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.
Are you referring to the "Unifying events and threads" paper? I'll take a look a bit later tonight. Is there a recommended place to contact this GHC HQ other than this cvs-ghc list? > > 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. I don't see why it won't work; if epoll_create fails with ENOSYS, we can just switch over to the select() loop. That said, I suppose kernels older than 2.5.44 are rather deprecated now, so it might not be necessary. I don't know whether other platforms than linux might need this sort of support though. _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
