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

 Here's my analysis on the allocate and performance difference:

 Mio's centre data structure is a fixed sized(32) stripped int-table(using
 grow only buckets), it maps fd to its callback function. The bucket
 usually is quite full since fd numbers follow the least unused rule.

 My libuv binding's centre data structure is variadic size(capatibily
 number) stripped int-table(also using grow only buckets), it map a range
 limited *slot* to a `MVar`. It actually works like a per capatibily stable
 pointer table: we keep a free list of slot waiting to be assigned, and
 during GC the int-table is evacuated.

 So mio have to allocate extra callback closure, even it's usually just a
 `putMVar`, but libuv doesn't: it simply use slots from eventloop to
 unblock those `MVar`s.

 Theoretically mio is more flexible since you can do pretty much anything
 inside callback, but in practise this's not a problem for libuv: after we
 unblock the blocking thread, it can do anything it want to, too.

 I plan to optimize the `MVar` table further using `primitive` 's
 `UnliftedArray` trick: it use `ArrayArray#` to directly save `MVar#` in
 packed memory. It will cut the GC time spending on the table(which is
 already very low) half. But i can't see how this optimization work out for
 mio.


 Another direction to go is to optimize our stable pointer's implementation
 and use the new `try_put_mvar` in 8.2. But I'm afraid it would not be as
 fast as my current version since current version is optimizied for libuv's
 call convention: provide buffers and handles, then wait for callbacks.

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