GNU bug report logs - #10243
8.14: ls --color is uninterruptible with ctrl+c (and no network fs in use)

Previous Next

Full log

Message #36 received at 10243-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: Pádraig Brady <P <at> draigbrady.com>,
	Arkadiusz Miśkiewicz <arekm <at> maven.pl>,
	10243-done <at> debbugs.gnu.org
Subject: Re: bug#10243: 8.14: ls --color is uninterruptible with ctrl+c (and
	no network fs in use)
Date: Thu, 08 Dec 2011 14:09:32 +0100

Eric Blake wrote:

> On 12/08/2011 03:05 AM, Jim Meyering wrote:
>> Starting with commit adc30a83, when using --color, ls inhibited
>> interrupts to avoid corrupting the state of an output terminal.
>> However, for very large directories, that inhibition rendered ls
>> uninterruptible for too long, including a potentially long period
>> even before any output is generated.
>> * src/ls.c: There are two phases of processing that are time-
>> consuming enough that they can cause this sort of trouble:
>> the readdir loop and the printing loop.  The printing side of things
>> was nominally covered by a call to process_signals in
>> (print_name_with_quoting): ... but that call was mistakenly guarded
>> by a condition that might be false for many or even all files being
>> processed.  Call process_signals unconditionally.
>> (print_dir): Also call process_signals in the readdir loop.
>
> Aren't there actually three phases of long processing?  You covered the

Not for today's systems.

> readdir loop, and printing, but what about time spent in sorting?  And
> if sorting is indeed a long enough processing hog, should we be calling
> process_signals in the qsort() callback as a reliable frequently reached
> point, or is that too dangerous?

It's not "long", as in noticeable with a 2-million-entry directory.
Sorting that many entries is quick enough that no change is needed.
Of course you can construct a situation in which sorting will take
too long, i.e., so little RAM that swapping is required, or so many
dir entries that sorting really does take too long, but on systems
where you don't run out of i-nodes first, a directory with that many
entries will cause you far more trouble than merely rendering ls
uninterruptible for a few seconds.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.