Re: [pcre-dev] PCRE2 and thread safety of jit compilation?

On Mon, Jan 4, 2016 at 12:43 PM, Zoltán Herczeg <hzmester@???> wrote:
> 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.

It is, and I agree. However the scenario I depicted was slightly
different. In PCRE1 I could have something like this:

/* global state */
pcre *code; /* initialized the results of a pcre_compile2 */
mutex m;
pcre_extra *extra; /* initialized to NULL */

With this one can safely have multiple threads matching using the same
code. The match would look like something like this:

pcre_extra *local_copy;
lock(mutex);
local_copy = extra;
unlock(mutex);
pcre_exec(code, local_copy, ...);

Now, if one thread also wanted to study/jit compile, it could do:

lock(mutex);
extra = pcre_study(code, ...);
unlock(mutex);
/* then proceed to match as usual */

Now in PCRE2 this possibility gets prevented by the fact that there
will surely be data races between one thread inspecting the pcre2_code
data structure for checking whether there's jit support available, and
another thread jit-compiling and setting the jit fields in the same
data structure.

For now, I've solved this problem by employing an external read/write
mutex -- threads which are matching match under a read mutex, threads
which want to jit-compile need to acquire the write mutex. But I feel
this may worsen the overall performances.

Thanks for the help,
--
Giuseppe D'Angelo