[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487A5082.6050704@firstfloor.org>
Date: Sun, 13 Jul 2008 20:59:14 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Ingo Molnar <mingo@...e.hu>, Roland McGrath <roland@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Elias Oltmanns <eo@...ensachen.de>,
Török Edwin <edwintorok@...il.com>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] x86_64: fix delayed signals
Linus Torvalds wrote:
>
> On Sun, 13 Jul 2008, Andi Kleen wrote:
>> At least the original report was about Ctrl-C only versus Ctrl-Z.
>
> Yes, and I explained why.
>
>> I see the problem regularly myself that Ctrl-C doesn't work,
>> but Ctrl-Z+kill does (although I unfortunately cannot
>> reproduce it on demand).
>
> There's no way you _can_ reproduce it.
That's not how I remember it from seeing it here, but ok it's possible my
memory is fuzzy and I'm misremembering. I'll continue to watch it.
While the bit about color ls (which I use here) catching signals was
also interesting I wouldn't expect the color ls to take longer to
process Ctrl-C even if it hits user space because it shouldn't
do anything block here (unless the terminal is in flow control,
but is unlikely)
> Two facts:
>
> - ^Z and ^C are both going to be equally fast if they aren't blocked.
>
> This is just how things are. They are handled by the same codepaths.
Yes I know that, that is why the behavior always puzzled me, because
it apparently contradicts that. I think I know reasonably well how
signals work, but cannot say the same about tty, so my guess was
in that area. But we'll see.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists