[GHC] #8400: Migrate the RTS to use libuv (or libev, or libevent)

[GHC]

#8400: Migrate the RTS to use libuv (or libev, or libevent)
-------------------------------------+-------------------------------------
        Reporter:  schyler           |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  635, 7353         |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonmar):

 I'm not familiar with `libuv`, but just to list the concerns I would have
 about replacing the IO manager:

 * Performance: the current IO manager was pretty heavily tuned and
 optimised when it was developed, the benchmarks and results are described
 in the Mio paper.  I'd like to see comparative results showing that libuv
 is at least as fast for the same benchmarks before we consider switching.
 Some performance issues can be subtle (e.g. unsafe FFI calls that take too
 long, or mutable data structures that affect generational GC performance),
 so even if the benchmarks are good we'd need to examine the code quite
 carefully.

 * Dependencies (as @bgamari pointed out) can be problematic. How would we
 handle the dependency? Import it into the tree (as with libffi), as a
 submodule (as with packages), or require it to be installed and test for
 it in configure (as with LLVM / gmp, but IIRC we're thinking of changing
 this for LLVM)?

 * Correctness: there is a history of subtle bugs in the IO manager and its
 interface with the rest of the IO library.  I don't know how best to avoid
 introducing new problems other than the regression test suite, but it's
 worth mentioning that this is an area we need to be especially careful.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8400#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler