[GHC] #7229: Detecting if a process was killed by a signal is impossible

[GHC]

#7229: Detecting if a process was killed by a signal is impossible
------------------------------+---------------------------------------------
 Reporter:  benmachine        |          Owner:                   
     Type:  bug               |         Status:  new              
 Priority:  normal            |      Component:  libraries/process
  Version:                    |       Keywords:                   
       Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple 
  Failure:  None/Unknown      |       Testcase:                   
Blockedby:                    |       Blocking:                   
  Related:                    |  
------------------------------+---------------------------------------------
 Currently there is no good way of detecting if a process was terminated by
 a signal. We have the following problems:

  * Firstly, the API doesn't make any allowance for it. This may be because
 the concept doesn't exist on Windows, I'm not sure. But since the concept
 ''does'' exist on POSIX, we do have to make a decision about what to do
 there (or if we have made one, document it).
  * `waitForProcess` attempts to give the signal in the exit code, but the
 underlying C function doesn't use the `WTERMSIG` macro. It so happens that
 on my system it works fine anyway, but it has no ''right'' to in principle
 (and in any case, what it does is both sub-optimal (in that getting killed
 by SIGINT is indistinguishable from returning 3) and undocumented).
  * The C function `getProcessExitCode` is much worse. When a process has
 exited due to a signal, it tests `WIFSIGNALED`, and if true, sets `errno =
 EINTR` (huh?) and returns `-1`. Since it is called from
 `throwErrnoIfMinus1Retry`, the result is that it immediately gets called
 again: but this time the child doesn't exist anymore. The behaviour in the
 case of `ECHILD` is, bizarrely, to pretend that there was a child and it
 exited with status 0, i.e. success. Which is just untrue.

 I don't know what the right behaviour is, but the above is both
 inconsistent and unhelpful. The lack of `WTERMSIG` is easily fixed, but
 that's the least of the problems here: we really need to work out what
 ''ought'' to happen before we start making it happen.

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