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

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

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

assert that we have one.



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

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

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

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

is set.



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

the thread-pool related params into a new file mgt_pool.c as proof.

The paramters happen in management process context, and should therefore
not end up in cache_* files for namespace and sanity reasons.



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

generic for comfort.



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

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

now.



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

of possibly relevant headers and only go with the fast path if we have
credible information that this is a big-endian platform.



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

In the end, it comes down to lack of POSIX definition of a way to find
out byte-endianess, sigh...



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

This does not do anything yet.



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

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

This code was written by Colin Percival for the FreeBSD project.



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

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

for the child object and pretend to send a 304 reply for them, if we have decided to
deliver the main object.

Fixes #386


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

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

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

Avoids build-dependency on binutils-dev


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

Make reservation and release explicit.

Add asserts that this it happens.


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

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

Only emit debug message for writes that fail


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

Thanks to Jonny @ globo for noticing.


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

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

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

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

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

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

in the FreeBSD original.

Approved by:	des


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

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

This isolates the mangement process from the compilers bugs
and memory usage.


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

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

The VCL file specified to -f must be read relative to the directory
from which varnishd is started, before we chdir to the workdir.

We used to deal with this by opening the file and passing the file
handle down.  It's simpler to just read the file and pass the actual
VCL code down.



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

memory



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

function, and give it the ability to limit how many lines of
output we get back from the subprocess, in order to muzzle the
C-compiler somewhat.



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

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

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