[GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager

[GHC]

#1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO
manager
-----------------------------------+---------------------------------
        Reporter:  simonmar        |         Owner:  (none)
            Type:  task            |        Status:  closed
        Priority:  lowest          |     Milestone:  7.6.2
       Component:  Runtime System  |       Version:  6.6.1
      Resolution:  wontfix         |      Keywords:
Operating System:  Linux           |  Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown    |     Test Case:
      Blocked By:                  |      Blocking:
 Related Tickets:                  |
-----------------------------------+---------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"9fc40c733ba8822a04bd92883801b214dee099ca/ghc"
 9fc40c73/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="9fc40c733ba8822a04bd92883801b214dee099ca"
 Refactor the kind-checking of tyvar binders

 The refactoring here is driven by the ghastly mess described in
 comment:24 of Trac #1520.  The overall goal is to simplify the
 kind-checking of typev-variable binders, and in particular to narrow
 the use of the "in-scope tyvar binder" stuff,
 which is needed only for associated types: see the new
 Note [Kind-checking tyvar binders for associated types] in TcHsType.

 Now

 * The "in-scope tyvar binder" stuff is done only in
      - kcLHsQTyVars, which is used for the LHsQTyVars of a
        data/newtype, or type family declaration.

      - tcFamTyPats, which is used for associated family instances;
        it now calls tcImplicitQTKBndrs, which in turn usese
        newFlexiKindedQTyVar

 * tcExpicitTKBndrs (which is used only for function signatures,
   data con signatures, pattern synonym signatures, and expression
   type signatures) now does not go via the "in-scope tyvar binder"
   stuff at all.

 While I'm still not happy with all this code, the code is generally
 simpler, and I think this is a useful step forward. It does cure
 the problem too.

 (It's hard to trigger the problem in vanilla Haskell code, because
 the renamer would normally use different names for nested binders,
 so I can't offer a test.)
 }}}

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