summaryrefslogtreecommitdiff
path: root/testsuite/tests/module/mod90.stderr
diff options
context:
space:
mode:
authorBen Gamari <bgamari.foss@gmail.com>2017-01-17 15:52:37 -0500
committerBen Gamari <ben@smart-cactus.org>2017-01-17 15:56:27 -0500
commitd5cd505bc484edee3dbd5d41fb7a27c2e18d528d (patch)
tree07b0bb680d1f1393940d703708bf8f0183549342 /testsuite/tests/module/mod90.stderr
parente7e5f7accbb7d9a12aee5d1468371a8ba09b598d (diff)
downloadhaskell-d5cd505bc484edee3dbd5d41fb7a27c2e18d528d.tar.gz
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: hvr, austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2957 GHC Trac Issues: #12038
Diffstat (limited to 'testsuite/tests/module/mod90.stderr')
0 files changed, 0 insertions, 0 deletions