GNU bug report logs -
#10243
8.14: ls --color is uninterruptible with ctrl+c (and no network fs in use)
Previous Next
Reported by: Arkadiusz Miśkiewicz <arekm <at> maven.pl>
Date: Wed, 7 Dec 2011 17:47:02 UTC
Severity: normal
Found in version 8.14
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
Full log
Message #35 received at 10243-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
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?
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 13 years and 170 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.