[module dev] PCRE compiled code lost at reload

Sergey Brester serg.brester at sebres.de
Wed Jun 22 09:47:33 UTC 2016


A little bit off-topic, but which benefits you think, you will get using
cross process compiled regexp? 

The compiling of regex is normally fast operation, that will be done
only once (even jit), and can be done in each worker.
What I cannot imagine, is the sharing of the result of regexp execution.
But not the regexp self.
Regards, sebres.

22.06.2016 11:31, MAGNIEN, Thierry wrote: 

> Hi,
> I'm experiencing a strange behavior and I wonder if I'm missing something obvious...
> I've developed a module and I use shared memory and slab allocations to keep data unique across workers and have data survive a reload.
> Everything works fine except one single thing: PCRE compiled codes (ngx_regex_compile_t->regex->code).
> To be more precise, at reload, in my module init function, I recompile some of the PCRE if they have changed, still using shared memory. What I notice is that, just after init module function has returned, all dying workers lose PCRE compiled code (regex->code = 0), where all new created workers correctly get new compiled code.
> I tried to use my own pcre_malloc function in order to be sure memory is allocated in shared memory (and this *is* the case), but without success.
> So any help is welcome: does anyone have a clue about why only those data are "lost" by dying workers ?
> Thanks a lot for your help,
> Thierry Magnien
> P.S.: I can't exhibit code for confidentiality reasons but if no one has a clue, I'll try to write a very simple module, only to exhibit this behavior.
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel [1]

[1] http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160622/af5d1b5d/attachment.html>

More information about the nginx-devel mailing list