[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:  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