Message-ID: <4868B5A8.2060004@aitel.hist.no>
Date: Mon, 30 Jun 2008 12:30:00 +0200
From: Helge Hafting <helge.hafting@aitel.hist.no>
Organization: HiST
User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509)
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
CC: Andi Kleen <andi@firstfloor.org>,
       =?UTF-8?B?VMO2csO2ayBFZHdpbg==?= <edwintorok@gmail.com>,
       Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Ctrl+C doesn't interrupt process waiting for I/O
References: <48661488.10304@gmail.com> <4866F6FE.9000503@goop.org> <8763rsphkt.fsf@basil.nowhere.org> <4867B20E.2030608@goop.org>
In-Reply-To: <4867B20E.2030608@goop.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1226
Lines: 29

Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
>> Still there's the effect that Ctrl-Z+kill works faster than Ctrl-C
>> that is not explained by this. This has often annoyed me too.
>> I'm not sure why it is. In theory they should be the same unless
>> someone blocks SIGINT.
>>   
> 
> I'd never noticed that.  That's just weird.
> 
I occationally see this - although I rarely run loads so heavy that it 
is a real problem. Ctrl-C - nothing happens except maybe a ^C printed - 
kill it from another rxvt.

Could it be some sort of tty locking issue, holding up Ctrl-C processing
while the heavily loaded machine suffer lock contention?

Last time I saw this was a erroneous script that called itself without
exec. With 2G memory and 3G of swap in use, the system was slow. the 
mouse cursor moved only now and then. Very little happened
with Ctrl-C. Closing the rxvt running this script then caused a lot of
disk activity and the system slowly came back to normal.

Helge Hafting
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/