[GHC] #2451: New signal-handling API

[GHC]

#2451: New signal-handling API
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:  simonmar    
        Type:  proposal          |       Status:  new         
    Priority:  high              |    Milestone:  6.14.1      
   Component:  libraries/unix    |      Version:  6.8.3       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by phunge0):

 Replying to [comment:18 simonmar]:
 > Replying to [comment:17 phunge0]:
 > >
 > > Given that the motivation was to share SIGCHLD among several code
 > > paths, I have a few questions:
 > >
 > > Suppose both System.Process and some other code has forked children.
 > > What should they do inside their signal handler? Typically they'd want
 > > to call wait(), but that might reap a child which had been forked by
 the
 > > other API, and then the other handler would never see that its child
 had
 > > exited. So doesn't the handling of SIGCHLD (i.e. the calling of
 wait())
 > > have to be a global thing?
 >
 > No - the SIGCHLD handler gets passed the pid of the process that died,
 so it can decide whether this process belongs to someone else, and if not
 reap it using waitpid().

 Really? My (vague) understanding is that a single SIGCHLD might be
 generated even though multiple children have exited -- i.e. SIGCHLD will
 not be queued the way real-time signals are. I see that w/ a test program
 which blocks SIGCHILD w/ sigprocmask -- 2 children exit, only one signal
 handler gets invoked.

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