stack vs workspace for pcre and others #1576

[Federico Schwindt]

I don't think you're considering all the implications.

Bundling something is no small feat, specially when bugs are found. The
libjemalloc problem is a good example.

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.

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.


On Tue, Sep 2, 2014 at 8:24 PM, Nils Goroll <slink at schokola.de> wrote:

> On 02/09/14 20:06, Federico Schwindt wrote:
> > What you mean not a disadvantage? Are you by any means suggesting to
> bundle pcre
> > with Varnish?
>
> If it saved considerable amounts of per-thread memory then I'd consider
> the option.
>
> Or, alternatively, realize that we need a larg-ish stack anyway and
> (re)adjust
> the rest of the code following this insight.
>
> > There is also this somewhat worrisome comment in the docs: PCRE runs
> noticeably
> > more slowly when built in this way.
>
> I thought the docs were referring to pcre_malloc and pcre_free pointing to
> malloc() and free(), respectively and I'd expect the overhead to be not
> that
> significant if we implemented pcre_malloc as moving the free pointer of a
> workspace (pcre_free probably could be a noop).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140902/84c43b7c/attachment.html>