[GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops

[GHC]

#8733: I/O manager causes unnecessary syscalls in send/recv loops
--------------------------------------------+------------------------------
        Reporter:  tibbe                    |            Owner:
            Type:  bug                      |           Status:  new
        Priority:  normal                   |        Milestone:  7.10.1
       Component:  Runtime System           |          Version:  7.6.3
      Resolution:                           |         Keywords:
Operating System:  Unknown/Multiple         |     Architecture:
 Type of failure:  Runtime performance bug  |  Unknown/Multiple
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by AndreasVoellmy):

 The approach you mention is actually what the IO manager pre 7.8 did,
 although it didn't have `threadWait{Read,Write}WithTimeout` methods, so
 you would have to code this via the lower-level interface in `GHC.Event`.

 In the 7.8 IO manager, the approach you describe won't quite work. The 7.8
 manager uses a separate `poll` instance to handle timeouts (much as you
 described) and uses `epoll` instances (one per HEC) to monitor files. The
 reason that we don't handle timeouts in the epoll instances anymore is
 that the 7.8 manager uses non-blocking calls to `epoll`, and it sometimes
 yields and moves to the back of the run queue of its HEC.  This often
 reduces the number of blocking foreign calls. But it means that `epoll`
 may not be called in a timely fashion, because it may wait for a bunch of
 busy Haskell threads on its HEC to finish. For that reason, we keep a
 separate Haskell thread monitoring a `poll` instance just for timeouts.

 In contrast, in the pre-7.8 IO manager, the IO manager thread always did a
 blocking `epoll` call, so it could use the earliest timeout as the timeout
 for the `epoll` call. It would then have to wait for at most one Haskell
 thread to finish after the foreign `epoll` call returns in order to grab
 the HEC and dispatch callbacks.

 Tighter integration of the IO manager and the scheduler might help here.
 With the integration, we may not need the trick of sending the IO manager
 to the end of the run queue. Then we could probably match the latency
 characteristics of the pre-7.8 manager (wait at most one Haskell thread to
 fire callbacks) and the throughput of the 7.8 manager.

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