Detecting if a process was killed by a signal is impossible
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 theWTERMSIG
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 testsWIFSIGNALED
, and if true, setserrno = EINTR
(huh?) and returns-1
. Since it is called fromthrowErrnoIfMinus1Retry
, the result is that it immediately gets called again: but this time the child doesn't exist anymore. The behaviour in the case ofECHILD
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.
Trac metadata
Trac field | Value |
---|---|
Version | |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/process |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |