event manager: Don't worry if attempt to wake dead manager fails
authorBen Gamari <bgamari.foss@gmail.com>
Tue, 10 Jan 2017 18:38:50 +0000 (13:38 -0500)
committerBen Gamari <ben@smart-cactus.org>
Tue, 10 Jan 2017 18:39:04 +0000 (13:39 -0500)
commit6de7613604216f65fae92d8066a078bf9cd3c088
treee60374d193ecf0565294fbe903f47e68ac874db2
parentfe8bc14fdaf1596cef008148cc9ff40cbce5e994
event manager: Don't worry if attempt to wake dead manager fails

This fixes #12038, where the TimerManager would attempt to wake up a
manager that was already dead, resulting in setnumcapabilities001
occassionally failing during shutdown with unexpected output on stderr.

I'm frankly still not entirely confident in this solution but perhaps it
will help to get a few more eyes on this.

My hypothesis is that the TimerManager is racing:

  thread                   TimerManager worker
  -------                  --------------------
  requests that thread
  manager shuts down

                           begins to clean up,
                           closing eventfd

  calls wakeManager,
  which tries to write
  to closed eventfd

To prevent this `wakeManager` will need to synchronize with the
TimerManger worker to ensure that the worker doesn't clean up the
`Control` while another thread is trying to send a wakeup. However, this
would add a bit of overhead on every timer interaction, which feels
rather costly for what is really a problem only at shutdown.  Moreover,
it seems that the event manager (e.g.  `GHC.Event.Manager`) is also
afflicted by a similar race.

This patch instead simply tries to catch the write failure after it has
happened and silence it in the case that the fd has vanished. It feels
rather hacky but it seems to work.

Test Plan: Run `setnumcapabilities001` repeatedly

Reviewers: austin, hvr, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #12038
libraries/base/GHC/Event/Control.hs