<div dir="ltr">I don't think you're considering all the implications.<br><br>Bundling something is no small feat, specially when bugs are found. The libjemalloc problem is a good example.<br><br>Leaving that aside the NO_RECURSIVE code in pcre is not the default. This code is likely much less exercised than the recursive one and bugs might be lurking there. FWIW the last entry I can find in the changelog is from Dec 2010.<br>
<br>But most importantly this would be shifting the problem from the stack to the workspace. This doesn't fix the problem, just makes it easier or harder, we don't know, to reproduce.<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Sep 2, 2014 at 8:24 PM, Nils Goroll <span dir="ltr"><<a href="mailto:slink@schokola.de" target="_blank">slink@schokola.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 02/09/14 20:06, Federico Schwindt wrote:<br>
> What you mean not a disadvantage? Are you by any means suggesting to bundle pcre<br>
> with Varnish?<br>
<br>
</div>If it saved considerable amounts of per-thread memory then I'd consider the option.<br>
<br>
Or, alternatively, realize that we need a larg-ish stack anyway and (re)adjust<br>
the rest of the code following this insight.<br>
<div class=""><br>
> There is also this somewhat worrisome comment in the docs: PCRE runs noticeably<br>
> more slowly when built in this way.<br>
<br>
</div>I thought the docs were referring to pcre_malloc and pcre_free pointing to<br>
malloc() and free(), respectively and I'd expect the overhead to be not that<br>
significant if we implemented pcre_malloc as moving the free pointer of a<br>
workspace (pcre_free probably could be a noop).<br>
</blockquote></div><br></div>