by glyn.normington:

I noticed this problem while reading the source code of Process.Signal. A discussion on
go-nuts ([1]) concluded that a feature request would be beneficial.

The problem is that one of two errors can be returned if the process terminates before
the signal is sent. If the caller wants to treat this situation as a soft error and
ignore it, she must check for both errors. Not only is this inconvenient, but it exposes
the implementation of Signal to the caller.

Signal starts by checking p.done() and, if this shows the process has terminated, Signal
returns errors.New("os: process already finished"). But if the process
terminates after p.done() has returned false but before Signal calls syscall.Kill, then
(apparently, see [1], but I can't find any documentation of this behaviour) syscall.Kill
will return syscall.ESRCH which will then be returned by Signal.

So the caller who wishes to ignore this error needs to test the Error() string of the
message and, if that compares false, also check to see if the error is syscall.ESRCH.
Not only is this inconvenient and potentially fragile, but it exposes the implementation
of Signal.

The solution is to return a consistent error which needs to be chosen carefully.
syscall.ESRCH seems a little risky to me because it relies on the implementation of
Signal and of syscall.Kill. It seems better for Signal to return a (possibly new)
os.XXXX error.

After choosing the appropriate error code to return, there are two solutions. One is to
fix up the current code so that the same error is returned regardless of whether
p.done() or syscall.Kill detects that the process has terminated.

However a much better solution, in my opinion, is to delete the p.done() check and lean
on the check performed by syscall.Kill. This solution removes a small race and ensures
that a consistent error code is returned. I would still recommend converting
syscall.ESRCH to an os.XXXX error to hide the implementation of Signal from the caller.
The other benefit of this solution is that it reduces the amount of code, which makes
the code easier to read and maintain.

Ian Lance Taylor disagreed with this solution (in discussion [1]) and thinks it would be
better to continue to issue p.done() but ensure that the error code is consistent. Ian's
objection to removing the p.done() check is that he is concerned about its effect on a
quite different race where the process in question terminates *and* its PID is reused.
This race is a known problem in *IX and not something that Go can or should address.
However, Ian was of the opinion that removing the p.done() check makes this race
(significantly) worse - a conclusion with which I disagree.

Let's analyse this second race. If the PID has already been reused before Signal is
called, the proposed change will make no difference and Signal will operate on the wrong
process (and the caller is out of luck). If the PID is reused after Signal has returned,
then the proposed change will again make no difference: Signal will fail and return a
non-nil error code.

The situation of concern to Ian is where the PID is reused in the window between Signal
being called and it returning. Deleting the p.done() check decreases the size of the
window and makes the situation of concern less likely. But also let's consider the
effect of decreasing the size of the window on the race. The effect is to increase the
probability that Signal will return before the PID is reused, which is a beneficial
effect: Signal will operate on the wrong PID a little less often.

[1]
https://groups.google.com/forum/#!searchin/golang-nuts/Process.signal/golang-nuts/2Zmut0tcnPE/wIsFGWmWz1MJ