Re: Visible Ctrl-C in latest kernels

[Joe Peterson <joe@skyrush.com>]

David Newall wrote:
> Willy Tarreau wrote:
>> I would not be surprized that it is what has caused delays for Ctrl-C
>> to take effect for some of us. As discussed in another thread on the
>> subject, the problem was relatively recent and not easy to reproduce.
>>   
> 
> I don't think so.  Joe Peterson raised A line of enquiry, which looked
> quite promising to me, in
> http://marc.info/?l=linux-kernel&m=121502197008293.  He observed weird
> behaviour with pgrp, and that doesn't seem to have been explored
> adequately.  I think it's worth highlighting that the code which sends
> the signal is the following snippet, from n_tty.c:
> 
>     if (tty->pgrp)
>             kill_pgrp(tty->pgrp, signal, 1);
> 
> 
> I wonder if pgrp has a value different than we expect?

David,

Subsequently, I determined that the issue I talked about in the above
referenced thread was a bug in bash.  Here is my post about this:

	http://marc.info/?l=linux-kernel&m=121537020432289&w=2

The bash author has developed a simple patch, and it should appear
(according to him) in the new bash version.

> I had an idea; it didn't work out as I expected, but it did produce a
> result that I can't immediately explain; and it might be relevant.  The
> following program, when executed in background (./testprogram &) stops
> at tcsetpgrp(), which is fine; and if then continued (fg), it is immune
> to the interrupt, quit and suspend keys.  However, it is not immune to
> those keys if executed in foreground (./testprogram).  As said, I can't
> immediately explain this, and it seems like it might be important...

When I run your program, foreground or background, it always completes
(i.e. 5 "." chars) - i.e., I cannot interrupt it before it finishes.
This seems different than what you see.

Given the nature of the bash issue, it does not seem related, at least
not directly.

						-Joe