On 12 Apr 2008, at 19:19, Poul-Henning Kamp wrote:
> Your patch breaks the convention that compiled code only calls VRT_*
> functions, you need to keep a VRT_re_test() wrapper around for that
> reason.
I'm not sure that's breaking that convention - the call chain is in
vcc_regexp and it's a te
Hi,
I mentioned to des previously that by going from trunk 2605 to 2614, my
load and level of context switches per second grew a lot (during peaks),
and sent a couple of graphs showing that.
I've now tracked the problem down to this particular patch. I can run
with the latest trunk (2629), and by
I was wanting to start looking at the vcl parser, and noticed that you
can't link against just libvcl to call VCC_CompileFile due to
VRT_re_test being called in vcc_string.c.
Although varnishd supports -C to parse only
The attached patch against trunk moves and renames the re_test method
i
In message <[EMAIL PROTECTED]>, Paul Nasrat w
rites:
>> The attached patch against trunk moves and renames the re_test
>> method into vcc_string.c so libvcl could be used outside of varnishd.
>-int
>-VRT_re_test(struct vsb *sb, const char *re, int sub)
>-{
Your patch breaks the convention that
On 12 Apr 2008, at 16:31, Paul Nasrat wrote:
I was wanting to start looking at the vcl parser, and noticed that
you can't link against just libvcl to call VCC_CompileFile due to
VRT_re_test being called in vcc_string.c.
Although varnishd supports -C to parse only
The attached patch against