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

 We don't have to deal with the hacks either if we have a clean design in
 Base that properly uses UTF16 internally as it should for Windows. My
 feeling on this, is that in order to get things like IOCP working
 correctly using libuv you still need to change a significant part of base.

 You still need to
  - define an new IODevice etc.
  - change the internal encoding of GHC to support both UTF16 and UTF32
 (there is some code for this from when simonmar rewrote the I/O manager
 but I'm not sure the state it's in).
  - somehow get the scheduler of libuv to interact nicely with that of the
 rts. You for instance still want to have async I/O using the non-threaded
 rts.
  - change functions such as openFile to create handles using
 `FILE_FLAG_OVERLAPPED`.

 Especially the second one is not trivial. Getting IOCP support and/or RIO
 functionality in is actually fairly trivial, but if you don't change the
 internal encodings of base, you'll just take a hit by having it convert
 from UTF16 to UTF32 and back to UTF16.

 I am working on an implementation the other way, moving the I/O manager
 into Haskell and reworking most of base to use the right internal encoding
 for each platform. It's based on Joey's patches https://github.com/Mistuke
 /ghc-win-io-system was the state before merging into base. So We'll have a
 way to compare the two approaches then to see which is best.

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