GHC.Conc - epoll event loop and circular dependencies

[Bryan Donlan]

On Fri, Feb 15, 2008 at 2:13 PM, Bryan O'Sullivan <bos at serpentine.com> 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.