[GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit()

[GHC]

#9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit()
-------------------------------------+-------------------------------------
              Reporter:              |            Owner:  simonmar
  AndreasVoellmy                     |           Status:  new
                  Type:  bug         |        Milestone:
              Priority:  normal      |          Version:  7.8.2
             Component:  Runtime     |         Keywords:
  System                             |     Architecture:  Unknown/Multiple
            Resolution:              |       Difficulty:  Unknown
      Operating System:  MacOS X     |       Blocked By:
       Type of failure:  Incorrect   |  Related Tickets:  9284
  result at runtime                  |
             Test Case:              |
              Blocking:              |
Differential Revisions:  Phab:D129   |
-------------------------------------+-------------------------------------

Comment (by Austin Seipp <austin@…>):

 In [changeset:"f9f89b7884ccc8ee5047cf4fffdf2b36df6832df/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="f9f89b7884ccc8ee5047cf4fffdf2b36df6832df"
 rts/base: Fix #9423

 Summary:
 Fix #9423.

 The problem in #9423 is caused when code invoked by `hs_exit()` waits
 on all foreign calls to return, but some IO managers are in `safe` foreign
 calls and do not return. The previous design signaled to the timer manager
 (via its control pipe) that it should "die" and when the timer manager
 returned to Haskell-land, the Haskell code in timer manager then signalled
 to the IO manager threads that they should return from foreign calls and
 `die`. Unfortunately, in the shutdown sequence the timer manager is unable
 to return to Haskell-land fast enough and so the code that signals to the
 IO manager threads (via their control pipes) is never executed and the IO
 manager threads remain out in the foreign calls.

 This patch solves this problem by having the RTS signal to all the IO
 manager threads (via their control pipes; and in addition to signalling
 to the timer manager thread) that they should shutdown (in
 `ioManagerDie()`
 in `rts/Signals.c`. To do this, we arrange for each IO manager thread to
 register its control pipe with the RTS (in
 `GHC.Thread.startIOManagerThread`).
 In addition, `GHC.Thread.startTimerManagerThread` registers its control
 pipe.
 These are registered via C functions `setTimerManagerControlFd` (in
 `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The
 IO
 manager control pipe file descriptors are stored in a new field of the
 `Capability_ struct`.

 Test Plan: See the notes on #9423 to recreate the problem and to verify
 that it no longer occurs with the fix.

 Auditors: simonmar

 Reviewers: simonmar, edsko, ezyang, austin

 Reviewed By: austin

 Subscribers: phaskell, simonmar, ezyang, carter, relrod

 Differential Revision: https://phabricator.haskell.org/D129

 GHC Trac Issues: #9423, #9284
 }}}

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