bug#9488: 23.2; `call-process' races with SIGCHLD handler

bug#9488: 23.2; `call-process' races with SIGCHLD handler

[Taylor R Campbell]

`call-process' relies on `wait_for_termination' to block until the
SIGCHLD handler has run for the synchronous subprocess.  But this is
not the condition that `wait_for_termination' guarantees on exit.
Rather, if `wait_for_termination' returns, then either

(a) there is no process having the same pid as the child had, or
(b) a SIGCHLD has been delivered.

If the subprocess has died, but no SIGCHLD has been delivered yet,
then `wait_for_termination' may return even though the SIGCHLD handler
has yet to run.  As an aside, these conditions are not sufficient for
`wait_for_termination' to return: it may block indefinitely if the
operating system has already delivered SIGCHLD and reused the pid
before control enters `wait_for_termination'.  I have not observed
indefinite blocking behaviour in practice, but only because pids don't
get reused very fast.

What I have observed is process exit values of 0 that should have been
nonzero on

GNU Emacs 23.2.1 (i386--netbsdelf, X toolkit) of 2011-03-02.

I noticed this because `M-x grep' sometimes prompts me with `grep -nH'
and sometimes with `grep -nH -e', in turn because

(call-process "grep" nil nil nil "-e" "/dev/null")

sometimes returns 0 and sometimes returns 1 depending on who wins the
race.

I have not tested newer versions of GNU Emacs, but a cursory glance at
the code suggests that while the relevant subprocess code has grown
more unmaintainably complicated, the problem persists.

bug#9488: 24.3.50; Zombie process left after call-process

[Paul Eggert]

No further comment, so I installed the patch as Emacs trunk bzr 111081
and am marking bugs 9488 and 12980 as done.