--- Begin Message ---
|
Subject: |
23.2; `call-process' races with SIGCHLD handler |
|
Date: |
Mon, 12 Sep 2011 20:14:11 +0000 |
|
User-agent: |
IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1 |
`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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: 24.3.50; Zombie process left after call-process |
|
Date: |
Mon, 03 Dec 2012 13:47:59 -0800 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
No further comment, so I installed the patch as Emacs trunk bzr 111081
and am marking bugs 9488 and 12980 as done.
--- End Message ---