<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Kristian,<div><br></div><div>It is very kind of you to respond so quickly!</div><div><br></div><div>I apologise for the C error; my colleague looking over my shoulder and reading this email with me had a laugh about it. However, even when I remove the line above and the two lines below (which could bring sp back into scope) the behaviour is identical. </div><div><br></div><div>Unpacking the C code sounds like great fun but in the meantime, shouldn't the call to VRT_SetHdr with the simple arguments (taken from examples by Poul and others) be benign (I have tried it with and without vrt-magic-string)?</div><div><br></div><div><div><font class="Apple-style-span" face="Courier"> C{</font></div><div><font class="Apple-style-span" face="Courier"> VRT_SetHdr(sp, HDR_REQ, "\013X-My-Own-Value:", "1");</font></div><div><font class="Apple-style-span" face="Courier"> }C</font></div></div><div><br></div><div>That segfault-ing Varnish may be one of my guilty pleasures notwithstanding, I have now searched for VMODs and have found a reference to them in the 'Documentation for trunk.' Curiously, they don't appear to be documented in the 'Documentation for the latest stable release' which was the path I was stumbling down. Unfortunately, our preferred development environment (PHP on Macs for delivery on Ubuntu) does not lend itself to rapid prototyping C modules. The inline C seemed to amenable to me faffing about for a bit until I get something working.</div><div><br></div><div>I have a client who is very concerned about the very first access to a not-yet-cached bit of information by many, many people all at the same time. Their preference is to receive a retry response rather than queue and wait for the backend to respond (it is an expensive request) if someone else has already accessed the URL but the cache has not yet been populated with its content. Is there a built-in that would be ideal for this scenario?</div><div><br></div><div>Many thanks,</div><div>Philip</div><div><br><div><div>On 20 Jan 2011, at 13:47, Kristian Lyngstol wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Jan 20, 2011 at 01:26:37PM +0000, Philip Prince wrote:<br><blockquote type="cite">I would like to use a C routine to set a value which I could pass on to<br></blockquote><blockquote type="cite">VCL. I have made this simple start derived from examples I have seen on<br></blockquote><blockquote type="cite">the web. I direct the request to a PHP file that streams out simulated<br></blockquote><blockquote type="cite">data. If I comment out the VRT_SetHdr I get the expected data, otherwise<br></blockquote><blockquote type="cite">I get an empty file.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">C{<br></blockquote><blockquote type="cite"> #include <stdlib.h><br></blockquote><blockquote type="cite">}C<br></blockquote><br>(...)<br><br><blockquote type="cite">sub vcl_miss {<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> C{<br></blockquote><blockquote type="cite"> void setmyownvalue () {<br></blockquote><blockquote type="cite"> VRT_SetHdr(sp, HDR_REQ, "\013X-My-Own-Value:", "1", vrt_magic_string_end);<br></blockquote><blockquote type="cite"> }<br></blockquote><blockquote type="cite"> setmyownvalue();<br></blockquote><blockquote type="cite"> }C<br></blockquote><br>You shouldn't define a function inside vcl_miss. And that function has no<br>knowledge of (sp).<br><br>You have to move the function definition out of vcl_miss if you intend to<br>use a function, then prototype it properly and pass sp along.<br><br>As for the actual VRT_SetHdr, I didn't really verify it, but the easiest<br>test is to try exactly what you want in normal VCL and run "varnishd -C -f<br>foo.vcl" which will give the resulting C code.<br><br><blockquote type="cite">It has to be easy; my apologies for being so thick. I have looked for VRT<br></blockquote><blockquote type="cite">documentation but I must be looking in all the wrong places...<br></blockquote><br>There's a reason for that: We don't encourage in-line C unless you:<br><br>A. Know C<br>B. Understand Varnish<br>C. Are willing to look through the source code.<br><br>This is likely to change somewhat with Varnish 3.0 and vmods.<br><br>As for A, the majority of issues I've seen people have with in-line C is a<br>lack of basic C experience. Not prototyping would be one such thing (which<br>any compiler will warn you about). Almost every time I get asked to look at<br>in-line C, there's also a NULL-check missing which would result in a<br>segfault.<br><br>And for B... Well, if you don't properly understand Varnish, it's unfair to<br>assume you will be able to write C code for it in a manner that wont<br>increase deforestation, segfault varnish or harm little children. And it's<br>likely that you can do what you want without in-line C.<br><br>The last one, C, might require some more explanation. In-line C was<br>designed as an emergency escape hatch that we got for free. Because VCL is<br>translated to C, in-line C isn't so much a "feature" as a short-cut. The<br>interfaces of VRT (Varnish Run Time, which VCL and in-line C use) are not<br>guaranteed to be stable, even between stable version of Varnish. It's<br>simply not a design goal. If we create extensive documentation for it, we<br>create an expectation that any in-line C you write will work on the next<br>release too. That makes development harder.<br><br>Vmods are designed to solve that problem: We make it easier to write _good_<br>in-line C code for Varnish that can be re-used and maintained. It will also<br>make it easier to see what interfaces we need to keep and which ones we can<br>drop.<br><br>Hope this both helped you with the original problem and explained why<br>in-line C documentation isn't available :)<br><br>- Kristian<br></div></blockquote></div><br><div>
<div><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; "><b>Philip Prince</b> SB MA MBCS CITP<br>Network Architect, Director</p><img moz-do-not-send="true" src="http://www.oxil.co.uk/Direct/OxilEmailLogo.jpg" alt="Oxil Software" width="227" height="132"><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; margin-top: 1em; "><b>Oxford Information Labs Limited</b></p><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; ">The Magdalen Centre<br>Oxford OX4 4GA</p><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; ">t: 01865 784294<br>d: 01865 582040<br>m: 07595 894469</p><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; font-size: small; ">Legally privileged/Confidential Information may be contained in this message. If you are not the addressee(s) legally indicated in this message (or responsible for delivery of the message to such person) you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet e-mail messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my firm or employer unless otherwise indicated by an authorised representative independent of this message. Please note that we do not accept any responsibility for viruses and we advise you to scan attachments.</p><p style="font-family: helvetica, arial, sans-serif; margin-bottom: 1em; font-size: small; ">Registered office: 37 Market Square, Witney, Oxfordshire OX28 6RE. Registered in England and Wales No. 4520925. VAT No. 799526263.</p></div>
</div>
<br></div></body></html>