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? Oleg.
