On Fri, Feb 11, 2011 at 12:21 PM, Chet Ramey <chet.ra...@case.edu> wrote:
>
> You do realize that this case is indistinguishable from the original
> scenario in question: the child gets the SIGINT, handles it, and exits
> successfully (or not). Have you actually not followed the discussion?
Umm. I'm the one who brought that ambiguity up in the first place. Go
back and read the end of the original analysis posting (not just the
part I had to quote AGAIN, just to get people to admit there is a
bug).
Illia is then the one who claimed it wasn't at all ambiguous, and
suggested the (totally wrong) patch.
So please, somebody from the bash camp finally just admit that I (and
Oleg) actually know what we are talking about, instead of trying to
derail the bug-report by "can't reproduce" or "I'm on OS X, so I don't
see it" or "haven't you followed the discussion" answers?
Will somebody _finally_ admit there is a race, and that bash has a
bug? Please? Instead of this continuing denial?
Here's a suggestion: only consider the child program to have "blocked"
SIGINT if you actually got an EINTR to the waitpid() system call.
Because if the child had exited _before_ you even did a waitpid(),
then the waitpid() will - even if bash gets a ^C - return the success
report rather than returning EINTR.
Now, there's still some room for a race and a bug (^C happens just as
the child is in the middle of exiting and the child exits with no
WIFSIGNALED but still isn't "ready" yet by the time the waitpid
happens), but at least the race condition should hopefully be much
much smaller.
Linus
