Bryan O'Sullivan 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.
We don't have any concrete plans for revamping the way multithreaded I/O is
done along the lines of Peng's research. The refactoring of the scheduler
is more likely to happen (our 2007 Haskell Workshop paper).
My feeling is that we should be improving the IO manager to use
epoll/overlapped IO/kqueue/whatever.
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,
I can see how it might work - at installation time we build a tiny object
file containing the settings for the current system, link it with the RTS,
and this gets looked up at runtime. (similarly to the way the IO library
detects whether it's running against a threaded or non-threaded RTS).
Still, it's a fiddle and I'm not sure it's really necessary. Are we really
likely to want to build GHC such that it can support Linux kernels with and
without epoll()? Making the decision at build-time seems reasonable to me.
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.
Agreed.
Bryan (Donlan) - you should try to coordinate with Felix Martini who is
(was?) working on adding support for Windows' overlapped IO [1].
Abstracting the IO manager interface in the way you described is a great
way to ensure that you guys can work without conflicting too much.
[1]
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-November/013487.html
> I do note that the current IOReq and Delay structures are very careful
> to strictify and unpack their members, though, so is there a known
> major cost associated with this?
No, just ordinary Marlow performance paranoia :-)
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
