Messages in this thread | | | Date | Mon, 25 Aug 2008 12:03:21 -0600 | From | Joe Peterson <> | Subject | Re: 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 > 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
| |