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

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

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

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

The defaults for thread_pool_min and thread_pools were wrong; fixed.


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

Added support for setting read timeouts for backend requests (first_byte_timeout and between_bytes_timeout), in addition to make the connect_timeout available for the bereq object in vcl_miss and vcl_fetch.

first_byte_timeout is a read timeout from the connection to the backend is created to when the first byte arrives. It can be set as a parameter to varnish, as a field in the backend declaration or as bereq.first_byte_timeout in vcl_miss and vcl_pass.

between_bytes_timeout is a read timeout between each read from the backend. It can be set as a parameter to varnish, as a field in the backend declaration or as bereq.between_bytes_timeout in vcl_miss and vcl_pass.

The time unit for these timeout values are seconds. NOTE: The connect_timeout previously used milliseconds as time unit, so beware.


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

Isolate more stuff in hash_slinger.h.

Remove hash_slinger from cache.h, include in .c's as necessary.

Save a malloc per objhead by putting a few fields into the objhead
for the hash_slingers to use.

Preinitialize the refcount when we precreate the objhead.

Move the hash-string allocation into HSH_Copy(), no point in
duplication of mandatory step.




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

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

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

Thanks to perbu for suggested documentation
Fixes 355


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

storage_file prints the maximum storage size, make malloc do the same,
for consistency.


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

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

Fixed compiling on Linux with -Werror set. Added mising prototypes, removed an unused function and added the ATTRIBUTE_UNUSED to the attribute list for the rb_wrap() macro which generated unused functions.


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

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

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

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

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

in a source-file.

(All the work is done by vcc generated code now)



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

gracefully with large number of objects.

Previously we kept all objects in a single array which resultined
in increasingly infrequent but increasingly demanding calls to
calloc(3) with the consequent massive memory copies.  We also did
not release memory again if unused.

Now we stripe the array into rows of 64k objects each.

This number is a compromise between space wastage, max 1MB on a
64bit machine, and the desire to not add and delete rows all the
time.  With 64k objects in a row, even on a very busy server would
only add a new row every 5...10 seconds during ramp up.

Delete unused rows, but keep a hysteresis of an entire empty row
to avoid silly add-delete-add-delete-add-delete behaviour at row
boundaries.

Streamline some of the functions a bit.

Fixes #210




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

now that this is no longer possible.



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

	set obj.ttl = 0s
means that the object is not hit again by actually using "-1" instead.

This works around the rounding error which otherwise causes the object
to be inside TTL for up to one second - epsilon.



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

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

Fixes #365



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

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

There is no NULL value for pthread_t and you have to call a function
to compare them.



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

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

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

instead of increasingly unwieldy macros.

Amongst other things, this will make it much easier to do lock
profiling, contest statistics, asserts etc.

This commit is largely mechanically generated and should not result in
any changed functionality.

Locks retain the "mtx" monicker, as a reminder that they are mutexes.

No performance impact expected.


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

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

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

Fixes #368


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