bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c

[Zev Weiss]

On Sat, Aug 20, 2016 at 07:34:20AM +0900, Norihiro Tanaka wrote:
> On Sat, 20 Aug 2016 07:25:06 +0900
> Norihiro Tanaka <address@hidden> wrote:
> > Hi Zev,
> >
> > Thanks for replying.  I say a reverse thing.
> >
> > I believe that there is no problem if only dfaexec() is thread safe.  In
> > other words, I think that variables that we must really move to support
> > multipthread are eolbyte, sbit and letters, newline only which depend
> > on eolbyte, and mbrtowc_cache[] and never_trail should be changed as the
> > value does not changed by other thread at running dfaexec() by marking
> > already set, and we can leave other static and global as syntax etc.
> > It will bring us to the saving of memory albeit only slightly.
>
> Ah, I replied for first patch, but my all comments are for second or
> later patches.  I agree for first patch entirely regardless of whether
> we support multithread or not.

Okay -- so your question is about the necessity of making operations 
other than dfaexec() thread-safe?  That's reasonable, though (obviously) 
I went ahead made the other operations thread-safe anyway.

1) It was, in some ways, simpler for me.  Rather than tracing through 
exactly when and how each variable was used to determine which could be 
safely left as globals, it was somewhat easier to just migrate all 
mutable global state into a context struct of some sort.

2) While it's not a terribly elegant approach (and certainly doesn't 
have to be this way), my current multithreading patch set actually does 
compile the regex separately (and concurrently) in each thread (for 
reasons similar to #1 above -- it was just simpler to do it that way).

3) Finally, and perhaps most compellingly in my opinion, especially 
since dfa.c is soon going to become a library component, it seems 
desirable for compilation etc. to be made thread safe anyway.  While 
grep doesn't really *need* to have it be thread-safe (and I'm guessing 
gawk and sed currently don't either), it doesn't seem all that 
unreasonable for an application to *want* to concurrently compile 
independent regexes, so it would seem a bit unfortunate to me for a 
library (gnulib) to not support that at all.


Zev