[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 have attached the heap profile, the previous `+RTS -s` seems to be a
 mistake(I don't have a clue why it report such a big different), mio do
 allocate more memory, but that much.

 The benchmark parameters are:

 {{{wrk -c1000 -d10s http://127.0.0.1:8888}}}

 The request rate are

 {{{
 libuv: Requests/sec: 264542.07
 mio: Requests/sec: 236880.75
 }}}

 > If we could make the libuv backend optional and keep the existing
 codepath then maybe I can see us merge this, but otherwise it seems like
 we should simply try to optimize what we have rather than throw the whole
 thing away.

 I personally feel no rush to change current base's I/O manager: it works
 well, and needed by GHCi. But since this ticket's purpose is to discuss
 the possibilities of integrate libuv, i would like to hear more.

 > native dependencies are bound to either increase the complexity of the
 build system (if we statically link) or dramatically complicate
 distribution (if we dynamically link).

 I'm interested in distribute my library with a statically linked libuv, is
 it possible with cabal? libuv is quite easy to build on unix, but i don't
 know the situation on windows, it seems require visual studio.

 >  Further, it looks like libuv doesn't even support all of the platforms
 which GHC supports (OpenBSD, for instance).

 This is definitely not true, Node.js officially support OpenBSD so i don't
 see a reason why libuv not. I guess OpenBSD is just not on their CI.

 > I strongly suspect there is some very low-hanging fruit in mio.

 Can't say for libuv branch, but I think i got some other low-hanging
 fruit, e.g. i'm preparing the patch for `primitive` since you asked. It
 will include the `PrimArray a` and `class Arr (marr :: * -> * -> *) (arr
 :: * -> * ) a | arr -> marr, marr -> arr`.

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