> On 03/07, Chet Ramey wrote:
> >
> > > So I don't think my patch is really doing what it _intends_ to do.
> >
> > Let's take a step back and approach this a different way. Instead of
> > trying to intuit whether or not the child did anything with the SIGINT,
> > let's try to make the race condition smaller.
>
> OK, I'll try to test this patch later to see if it make the difference...
> At least the subjective difference.
>
> But,
>
> > The following patch is a very small change to jobs.c that makes
> > wait_sigint_handler only pay attention and set wait_sigint_received when
> > the shell is actually in waitpid() waiting for the child. It uses a
> > semaphore around the call to waitpid to effect that, with a little
> > bookkeeping and cleanup code. When the shell gets a SIGINT while not
> > actually waiting for a child, it restores the old handler and sends
> > SIGINT to itself.
>
> Hmm. It is very possible I do not understand the patch correctly.
>
> But doesn't this patch introduce another problem?
>
> > *** 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.
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/
