[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 duncan):

 Replying to [comment:24 phunge0]:

 > Suppose the second waitable process belongs to System.Process, but the
 first waitable process belongs to something else?

 You're quite right. I had assumed that we could iterate through the list
 of waitable child processes, but it looks like if we do not reap the first
 then we never get shown the second.

 > Suppose we call the normal waitpid() instead, and if we find a PID which
 isn't ours, we stash the status in a temp buffer, to be returned the next
 time someone else calls System.Posix.getAnyProcessStatus?

 We must not reap processes that do not belong to us, it's not just the
 Haskell API, it's other C libs in the same process as us. In the worst
 case we could just call waitpid(pid, WNOHANG) to poll all the pids we are
 managing. That's a bit ugly when we're managing a lot of processes.

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