Wouldn't it be faster to move all of the I/O stuff into the RTS as C and
#8400: Migrate the RTS to use libuv (or libev, or libevent) ----------------------------+---------------------------------------------- Reporter: schyler | Owner: simonmar Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Runtime | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Project (more than a week) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: 635, 7353 Type of failure: | None/Unknown | Test Case: | Blocking: | ----------------------------+---------------------------------------------- Comment (by tibbe): Replying to [comment:4 schyler]: then only end up back in haskell-land when an fd event is finished? As I mentioned do *something* in the RTS instead of in a separate Haskell thread is probably going to be somewhat faster than what we do today.
In this case, libuv is probably appropriate.
It will likely not work, as libuv want to own the thread to drive the event loop. The scheduler needs to own the thread for it to work. Perhaps we could run libuv in a separate thread like we do with the I/O manager today. I also don't know if libuv is thread safe. We most likely want to make some assumptions/optimizations based on our special needs and I'm not sure if libuv can support that efficiently. In the end performance will probably be best if we call the underlying system calls directly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler