Ah i see. So basically if we have an expensive operation, like a DB call (as an example), we would have to re-do it every time we use the Vmod function inside the VCL.  The issue i am having is i have a vmod, where i would like to return a complex struct but i cant seem to be able to do that due to limitations on the return types.  So i was planning on writing accessor methods (one for each element of the struct) but for each accessor, i would need to re-query the database to get the value which was trying to avoid.<div>
<br></div><div>Example: </div><div><br></div><div>typedef struct  _mydata { </div><div> int val1;</div><div> int val2;</div><div>} mydata ; </div><div><br></div><div> i would love to return mydata from the vmod, but instead i need to write vmod_get_int1, vmod_get_int2 to get at these.  The issue is to populate this struct is "expensive".  Is there a better way around this issue ?</div>
<div><br></div><div>Cheers.<br><div><br></div><div><br><br><div class="gmail_quote">On Mon, Sep 12, 2011 at 5:48 PM, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In message <<a href="mailto:CANZWjw5t%2BQ0iEa-5rN6xriuy6Kw7i8Auq-z_vGj5uBKw9_gpog@mail.gmail.com">CANZWjw5t+Q0iEa-5rN6xriuy6Kw7i8Auq-z_vGj5uBKw9_gpog@mail.gmail.com</a>><br>

<div class="im">, AD writes:<br>
<br>
> I am trying to use the PRIV_CALL capability of the vmods in order to cache<br>
>an expensive operation used later in the vcl itself.<br>
<br>
</div>That is not how it works.<br>
<br>
PRIV_CALL is for caching things for the next time this call is executed.<br>
<br>
The canonical example is a caching a compiled regexp.<br>
<br>
What you need is a "PRIV_SESS" or "PRIV_REQ" variable, and I'm beating<br>
my head against the wall trying to find the best way to implement<br>
that as we're speaking...<br>
<br>
<br>
--<br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
<br>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</blockquote></div><br></div></div>