Hi,
the JIT compilation itself should be thread safe as before (no global variables are used for compilation). You can compile multiple patterns on multiple threads in the same time, and you can even use a pattern while JIT compilation is in progress on another thread. In theory at least, let me know if you encounter any problems.
However, if you compile the same pattern multiple times in different threads there will be (unrecoverable) memory leaks. The compilation which finishes last overwrites the previous data. This cannot happen with single thread compilation, since the compiler checks whether a given mode is compiled before (the appropriate entry is non-NULL). However, if the compilation is in progress, and the NULL has not been changed yet (kind of a racing condition), it starts another compilation. I think to avoid such situations is the application responsibility.
Regards,
Zoltan
ph10@??? írta:
>On Sun, 3 Jan 2016, Giuseppe D'Angelo wrote:
>
>> In PCRE2 the extra studying APIs / study data parameter were removed.
>> (Apparently studying is cheap enough that it's always done during
>> pattern compilation.)
>
>Yes, it seemed like a good idea to remove the (apparently) unnecessary
>complication, and always gain the performance advantage.
>
>> Now the optional study step is only done when JIT compiling a pattern
>> through pcre2_jit_compile, which operates on the very same pcre2_code
>> object returned by pcre2_compile.
>>
>> However, this opens a question about the thread safety of this
>> operation. Say we have the scenario depicted above -- two threads both
>> matching using the same compiled pattern, but one thread decides to
>> also jit-compile the pattern. Is this combination threadsafe? If not,
>> are there any recommended workarounds?
>
>We need Zoltán to answer this in detail, but looking at the code makes
>me think this is not thread-safe. It's not a scenario that had occurred
>to me.
>
>If there is no other workaround, I suppose the only thing to do is to
>have some kind of lock that stops other threads from calling
>pcre2_match() while one of them is running pcre2_jit_compile() for the
>same compiled pattern. This does not sound very satisfactory.
>
>I have made a note to update the documentation to cover this situation,
>once we have got clarification (and decided whether or not to change
>anything).
>
>Philip
>
>--
>Philip Hazel
>--
>## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
