#7229: Detecting if a process was killed by a signal is impossible
----------------------------------+-----------------------------------------
Reporter: benmachine | Owner:
Type: bug | Status: new
Priority: high | Milestone: 7.6.2
Component: libraries/process | Version:
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
----------------------------------+-----------------------------------------
Comment(by andersk):
While that’s a small improvement over the previous undocumented behavior,
it’s still not a real solution. In Unix programming, it’s important to be
able to reliably distinguish between `WIFEXITED(status)` (e.g.
`exit(130)`) and `WIFSIGNALED(status)` (e.g. `raise(SIGINT)`), so that one
can implement WCE (wait and cooperative exit) on `SIGINT`. The 128 +
signal thing that you see in your shell is specific to your shell; real
languages do make this distinction.
Really the right answer is to add a constructor to `ExitCode`. While
we’re doing that, we should expose `WCOREDUMP(status)` for completeness:
`ExitSignaled {exitSignal :: Int, exitCoreDump :: Bool}`.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7229#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
