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@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org