#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 simonmar): Agree with everything that @thoughtpolice said. Also, I'm not generally swayed by arguments of the form "we should use library X because it is actively maintained and does job Y that we already do", because external dependencies have their own costs - let's not forget we've had problems with all of gmp, libffi and LLVM. There are benefits to being in control of your own code, and when the functionality already exists and works (as in the case of the rts code) it's an unforced change. These things are never black and white, and we have to weigh up any benefits we might get against the costs of incurring an external dependency. I just want to point out that we shouldn't add new dependencies without thinking very carefully. @tibbe: I suggest first identifying the problem that would be solved by moving the I/O manager into the RTS. Identify where we have extra latency, and explain why it can't be solved in Haskell. Moving the I/O manager wholesale into the RTS is a huge job, because you don't get to take advantage of nice things like atomicModifyIORef and immutable data structures, and the interaction with the scheduler is likely to be very tricky indeed. There would need to be significant payoff. Adding small hooks is a better approach, if we can find out what hooks would help - e.g. per-thread state is something we don't have a good way to do right now, and would be a generally useful thing to add. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8400#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler