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