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