|
From: | Paul Eggert |
Subject: | [bug-diffutils] bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: [PATCH] diff: add support for --color |
Date: | Sat, 12 Sep 2015 08:52:14 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
Giuseppe Scrivano wrote:
Paul Eggert <address@hidden> 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.
[Prev in Thread] | Current Thread | [Next in Thread] |