Avoid race condition with Popen.send_signal

[Adam Skutt]

On Jan 2, 11:53 pm, Cameron Simpson <c... at zip.com.au> wrote:
> On 02Jan2012 19:16, Adam Skutt <ask... at gmail.com> wrote:
> | On Jan 2, 8:44 pm, Cameron Simpson <c... at zip.com.au> wrote:
> | > On 02Jan2012 20:31, Devin Jeanpierre <jeanpierr... at gmail.com> wrote:
> | > | > I think that catching the exception is probably the most Pythonic way.
> | > |
> | > | It's the only correct way.
> | >
> | > Indeed, but be precise - chek that it _is_ error 3, or more portably,
> | > errno.ESRCH. POSIX probably mandates that that is a 3, but the symbol
> | > should track the local system if it differs. Example:
> |
> | No. It is possible (however unlikely) for EPERM to be legitimately
> | returned in this case.  Anything other than EINVAL should be
> | interpreted as "The child process is dead".
>
> Sure. I was more taking the line: catch and accept only the specific
> errors you understand.

That advice really only applies when we have interfaces that don't
fully define their exceptional conditions.  That's not the case here.
Though I should correct myself and note that EPERM can only occur if
SIGCHLD is being handled in a non-default fashion.  That being said,
I'm not sure any error code should be treated differently from another
here.

> Of course he can catch EPERM also. But any other
> variant should at the least generate a warning to stderr or a log
> it is _unexpected_.

Are they really unexpected though?  Even if they are, what is logging
an error going to gain anyone?  Even crashing may not be helpful,
especially given that there have been bugs in the past with the return
codes from kill(2).  Certainly, I'd be far more concerned about
ensuring my code doesn't accidentally kill the wrong process than
worrying about ensuring it handles the return code from kill(2)
correctly.

> I take your point that reraising the exception may be overkill for
> failed signal delivery (if that was your point). But I am arguing for
> being very careful about what you silently pass as an ok thing.
>

Trapping too few conditions is just as erroneous as trapping too
many.  This is especially true when dealing with UNIX system calls.
The right behavior is frequently not as simple as it may appear,
unfortunately.

> | Hence why you should
> | avoid sending the signal in the first place: the situations where you
> | don't run the risk of possibly killing an innocent bystander are
> | pretty narrow.  While unlikely on modern UNiX and Linux, IMO it's best
> | to avoid the issue altogether whenever possible.
>
> Fair enough too. But sometimes you need to nail a rogue child.

Even if I believed that were true, I wouldn't use SIGINT to do it.

Adam