GNU bug report logs -
#20062
[PATCH] diff: add support for --color
Previous Next
Full log
Message #167 received at 20062 <at> debbugs.gnu.org (full text, mbox):
Giuseppe Scrivano wrote:
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> Giuseppe Scrivano wrote:
>>> Would block signals between a set_*_color_context and
>>> reset_color_context be enough or do we need more granularity (there are
>>> many places where printf is used in the code)?
>>
>> No, for reasons Eric described: output is buffered.
>
> can't we solve this by flushing the output before enabling signals?
"enabling"? Do you mean, flushing the output when a signal is caught? No, that
won't work, as stdio is not safe in the presence of signals. Or do you mean
fflush the output before unblocking signals? Yes, that will work, but it's slow.
> we already had this discussion about an older version of the patch where
> signals were processed after every line. We agreed that one difference
> between ls and diff is that ls has a limit on the line length, while
> diff hasn't such a limit and as you noted, it is bound only to the
> available memory. This was the reason for reacting to signals as soon
> as diff receives one.
Sorry, I don't remember that discussion. Yes, the point is a valid one, and
needs to be addressed.
> Either we block signals or we catch them and process as ls does (calling
> 'process_signals' periodically) that problem will still be present.
True. However, blocking signals means we'll need to periodically
fflush-unblock-block, which will slow us down; the whole point of stdio is
efficiency via buffering, after all. Doing it the 'ls' way avoids this
overhead, as we'll need to fflush only when a signal has actually arrived, plus
we avoid the syscall overhead of periodic unblock-block.
This bug report was last modified 8 years and 78 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.