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

 I'm aware of your effort actually, it's here:[https://github.com/Mistuke
 /ghc-win-io-system/] isn't? And i'm sure you are an windows expert ;)

 The old `IODevice` typeclass is not satisfactory and i indeed want to
 define new one. The encoding problems in base use functions from C runtime
 on windows instead of using windows API directly, which is the culprit
 IMO. Because most of the windows API have wide-char version which can
 directly use UTF-16, isn't?

 But libuv really solved most of those problems VERY WELL. for example it
 mapped window console API to accept ansi escaped code, so we get colorful
 ansi terminal for free, and it does the heavy work to shim the UTF-16
 encoded `readConsoleInputW/writeConsoleOutputW` to accept UTF-8 buffers,
 which reduced much of the headache.


 The real remaining problem is how to make libuv with with ghc's scheduler,
 which i think i have a plan, i describe it in the github link above,
 please have a look.


 Finally, if we can manage leverage libuv to do I/O in haskell, we can save
 lots of repeated work, libuv is really an all-in-one solution for I/O
 problems: tcp, pipes, process, file watchers, etc. You name it!

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