On Fri, 19 Aug 2016 18:03:19 -0500 Zev Weiss <z...@bewilderbeest.net> wrote:
> 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 Thanks. dfa exists only to improve performance of regex and regex uses static variable for syntax which is re_syntax_options. So we can not still change compile phase thread-safe. In addition, IMHO, I think that compile should run only one time even if grep runs multithread as you say in 2, and I do not expect that members used in only compile not used in execute is generated each more than one. BTW, mbcsets, nmbcsets and mbcsets_alloc use in only compile, so I think that they may be also put out of struct dfa in future. (That isn't always to move them to static or global) Norihiro
