[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c
From: |
Norihiro Tanaka |
Subject: |
bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c |
Date: |
Sun, 21 Aug 2016 08:40:59 +0900 |
On Fri, 19 Aug 2016 18:03:19 -0500
Zev Weiss <address@hidden> 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
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, (continued)
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Norihiro Tanaka, 2016/08/19
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Zev Weiss, 2016/08/19
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Norihiro Tanaka, 2016/08/19
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Norihiro Tanaka, 2016/08/19
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Zev Weiss, 2016/08/19
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c,
Norihiro Tanaka <=
- bug#24260: [PATCH 1/6] dfa: thread-safety: remove 'dfa' global in dfa.c, Zev Weiss, 2016/08/20
bug#24259: [PATCH 3/6] dfa: thread-safety: move parser state into struct dfa, Zev Weiss, 2016/08/18
bug#24259: [PATCH 5/6] dfa: thread-safety: eliminate static local variables, Zev Weiss, 2016/08/18
bug#24259: [PATCH 2/6] dfa: thread-safety: move lexer state into struct dfa, Zev Weiss, 2016/08/18
bug#24259: [PATCH 4/6] dfa: thread-safety: move regex syntax configuration into struct dfa, Zev Weiss, 2016/08/18
bug#24259: [PATCH 6/6] dfa: thread-safety: initialize mbrtowc_cache in dfa_init(), Zev Weiss, 2016/08/18
bug#24259: [PATCH 0/6] dfa: thread safety, Jim Meyering, 2016/08/20
bug#24259: [PATCH 0/6] dfa: thread safety, Paul Eggert, 2016/08/23