On 3/7/11 12:42 PM, Oleg Nesterov wrote:
> On 03/07, Chet Ramey wrote:
>>
>>> On 03/07, Chet Ramey wrote:
>>>>
>>>> *** 3090,3096 ****
>>>> --- 3099,3107 ----
>>>> waitpid_flags |= WNOHANG;
>>>> }
>>>>
>>>> + waiting_for_child++;
>>>> pid = WAITPID (-1, &status, waitpid_flags);
>>>
>>> OK, and what if ^C comes before waiting_for_child++ ?
>>>
>>> IIUC, in this case bash exits and leaves the current application
>>> (say, emacs which threats SIGINT specially) alone, no?
>>
>> Yes, it does. However, the same problem exists now. There is a window
>> between the time bash forks, the child execs, and bash waits when a SIGINT
>> can arrive and the same thing will happen.
>
> OK... I seem to understand.... make_child() blocks SIGINT, but at this
> point the signal handler is SIG_DFL. And then it forks and unblocks the
> signal without installing the handler.
>
> Thanks. I am just curious, is this another bug/problem or this was
> intended?
Intended. The SIGINT gets blocked so the internal state doesn't get
messed up (and we want the fork to complete). The wait signal handler
is only for when we're actually waiting for the child. (And it's not
always SIGDFL -- this same code path is executed by interactive shells,
too.)
While it is a race condition, this one's really, really hard to hit.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
