[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] Bash not reacting to Ctrl-C

From: Oleg Nesterov
Subject: Re: [BUG] Bash not reacting to Ctrl-C
Date: Mon, 7 Mar 2011 17:38:40 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]