GNU bug report logs - #23269
new snapshot available: grep-2.24.13-bed6

Previous Next

Full log

View this message in rfc822 format

From: Zev Weiss <zev <at> bewilderbeest.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: sur_behoffski <at> grouse.com.au, arnold <at> skeeve.com, 23269 <at> debbugs.gnu.org
Subject: bug#23269: Multi-threaded operation, mbrtowc, and "untangle" script [was Re: bug#23269...]
Date: Sun, 24 Apr 2016 19:18:22 -0500

On Thu, Apr 21, 2016 at 07:43:29AM -0700, Paul Eggert wrote:
>On 04/21/2016 02:55 AM, arnold <at> skeeve.com wrote:
>>it
>>would be a very suprising change in behavior if output from multiple
>>files comes out interleaved, instead of in the order the files were
>>specified on the command line.
>
>I presume that computation is interleaved but the output order is the 
>same as before, unless the user specifies an option saying speed 
>trumps predictability.
>

For what it's worth, the command-line flag added by my multithreading 
patch series as it currently stands is pretty much that (speed over 
predictability).  In the interest of simplicity, it omits per-file 
output buffering and just outputs matching lines as they are found -- 
the non-determinism this introduces into its output is the reason it's 
left as an opt-in command-line flag and not on by default.

[Strictly speaking even in the default "single-threaded" mode it *is* in 
fact actually multi-threaded, but there's only one search thread, so 
output ordering is unaffected.  In theory even this could allow a slight 
performance improvement by overlapping pattern-matching with directory 
traversal and prefetching in the master thread, but I'd guess it's 
probably negligible in most cases, and isn't really the goal of the 
patches.]


Zev Weiss

Previous Next

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