#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: |
----------------------------------+-----------------------------------------
Changes (by simonmar):
* priority: normal => high
* difficulty: => Unknown
* milestone: => 7.6.2
Comment:
I have adopted the shell convention of using 128 + signal number as the
exit status for a process that died due to a signal. Symbolic constants
for the signal names are available from `System.Posix.Signals`. I've also
fixed the slightly strange behaviour of `getProcessExitCode` - I dug
through the logs a bit, but the current code goes back a long way and I
couldn't find the reason for fixing `EINTR`.
Would anyone object to this going into 7.6.2? There is a semantic change,
but it is very unlikely that anyone was depending on the old behaviour.
We would need a minor version bump to `process` so that clients can
conditionally depend on the new behaviour.
patches to `process` package:
{{{
commit 54038240284b11ad4117ca075fa2292f5069bc45
Author: Simon Marlow <marlo...@gmail.com>
Date: Mon Sep 24 09:50:24 2012 +0100
Use (128+signal) as the exit code when a proc terminates due to a
signal (#7229)
commit 9547cf40ac1ddcd471a8ce75f927b382a82c1038
Author: Simon Marlow <marlo...@gmail.com>
Date: Mon Sep 24 12:11:14 2012 +0100
Test for #7229
commit 007fb056f2e77e65196de4bff94ea001e69a12eb
Author: Simon Marlow <marlo...@gmail.com>
Date: Mon Sep 24 12:27:43 2012 +0100
Documentation for signal exit codes (#7229)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7229#comment:3>
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
