[lkml]   [2008]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Visible Ctrl-C in latest kernels
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
> 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?


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:

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.


 \ /
  Last update: 2008-08-25 20:07    [W:0.056 / U:9.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site