git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2278 d4fa192b-c00b-0410-8231-f00ffab90ce4

storage chunks.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2277 d4fa192b-c00b-0410-8231-f00ffab90ce4

to parse due to lack of bytes.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2276 d4fa192b-c00b-0410-8231-f00ffab90ce4

parts, otherwise we will get trouble (#167 ?) later.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2275 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2274 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2273 d4fa192b-c00b-0410-8231-f00ffab90ce4

evaluated even if we don't bother to check the result.  We should trust
the compiler to eliminate code that has no effect.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2272 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2271 d4fa192b-c00b-0410-8231-f00ffab90ce4

to feed to h_ncsa(), so it is up to h_ncsa() to interrupt it if reopen
is non-zero.

Also remove a superfluous call to VSL_Arg() as was previously done in
varnishlog(1).


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2270 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2269 d4fa192b-c00b-0410-8231-f00ffab90ce4

we get around to delete the kevent.



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2268 d4fa192b-c00b-0410-8231-f00ffab90ce4

do anything about the associated session.

May be relevant relative to: #162

(Bitmap functions slightly general, for possible later reuse)



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2267 d4fa192b-c00b-0410-8231-f00ffab90ce4

Don't take a detour around cache_response.c, go directly to
cache_synthetic.c.

Don't wast time and energy mucking about with pseudo-objects,
just synthesize the error body directly in the workspace and
send it from there.

Close the session after sending error response, freeing up
resources sounds like a good strategy. (XXX: for futher study).

This might be related to #167



git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2266 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2265 d4fa192b-c00b-0410-8231-f00ffab90ce4

given circumstances is fair game.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2264 d4fa192b-c00b-0410-8231-f00ffab90ce4

Collect any messages from the C-compiler and pass them on to the
user, but do not take them as evidence of a failed compilation,
check the returnvalue for that.

To avoid confusion, explicitly say when the VCL program was compiled.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2263 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2255 d4fa192b-c00b-0410-8231-f00ffab90ce4

from which it tries to extract as much useful information as possible before
it croaks.  The corresponding macro is spassert(), which assumes you have
a struct sess *sp in scope.  This should help a lot with bugs like #167
where important information is not available post-mortem (because sp->obj
points into the cache, which is not included in the core dump)


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2254 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2253 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2252 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2251 d4fa192b-c00b-0410-8231-f00ffab90ce4

requires the child to be restarted or the VCL script to be reloaded.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2250 d4fa192b-c00b-0410-8231-f00ffab90ce4

important functional change is that the source is no longer piped to the
compiler; instead, the source file name (which now ends in .c) is passed
on the command line.  This makes it *much* easier to support non-GNU
compilers.

The cc_command parameter processed by a custom function instead of sprintf;
"%s" is replaced with the source file name, "%o" is replaced with the output
file name, and "%%" is replaced with a single "%".


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2249 d4fa192b-c00b-0410-8231-f00ffab90ce4

placeholder characters after the placeholders.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2248 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2247 d4fa192b-c00b-0410-8231-f00ffab90ce4

with it.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2246 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2243 d4fa192b-c00b-0410-8231-f00ffab90ce4

can't delay disarming it, or we will have a race between the acceptor and
a worker thread.  This will need revisiting at some later date.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2232 d4fa192b-c00b-0410-8231-f00ffab90ce4

press 3 for 2^3 = 8 seconds)


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2231 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2230 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2229 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2228 d4fa192b-c00b-0410-8231-f00ffab90ce4

on Solaris, so simply checking for their presence is not enough)


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2227 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2226 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2225 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2224 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2223 d4fa192b-c00b-0410-8231-f00ffab90ce4

git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2222 d4fa192b-c00b-0410-8231-f00ffab90ce4

the thread ID in order to locate the correct thread in gdb.  Furthermore,
we must use VSL rather than WSL since the session might actually not have
a worker at that point; but if it does, make sure to flush the log first.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2220 d4fa192b-c00b-0410-8231-f00ffab90ce4

along with some vital statistics, and flush the log regularly.


git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2215 d4fa192b-c00b-0410-8231-f00ffab90ce4