Re: [Grep-devel] [PATCH 0/4] search backend thread safety

[Zev Weiss]

On Sun, Dec 25, 2016 at 08:49:30AM -0800, Paul Eggert wrote:
> Although this patch seems like a good idea for general applications, 
> could you explain why it helps grep in particular? grep compiles the 
> r.e. in the main thread, and presumably will use it in subthreads. 
> After compilation, the compiled r.e. should never change, so it should 
> be OK for grep to keep it in a global variable shared among the 
> subthreads.

> From what I can tell that seems to be the case for some of the global 
variables I moved into struct parameters, but not all.  For example, 
pcresearch.c's jit_stack is modified during the execute phase, as is the 
dfa and re_pattern_buffer in dfasearch.c.

Given that *some* data (e.g. the dfa produced by GEAcompile() and 
altered in EGexecute()) is going to need to be replicated per-thread, it 
seemed simplest to me to just localize all (non-const) globals across 
the board -- it makes it simpler for someone reading/modifying the code 
(e.g. me adding multithreading) to verify that data isn't being shared 
between threads, avoiding having to trace through everything to see 
which variables are actually mutable and which are effectively read-only 
after initialization.

(The localeinfo struct in dfasearch.c is an exception I missed because 
the original versions of these patches that I've been rebasing 
periodically predate the existence of that variable, though it seems 
like that one might actually be more at home in grep.c anyway -- if no 
one disagrees, perhaps the attached patch could be applied.)


Zev

0001-grep-move-localeinfo-to-grep.c.patch
Description: Text Data