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

Change the .tcl script corresponding to r3364, fixes build failure


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

This will be skipped on platforms where srandom(1) does not result
in the same deterministic sequence of random numbers as on FreeBSD
and Linux.



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

srandom(1) and stops the test if we do not get the same sequence
as we expect.

The Open Group does not define which deterministic sequence srandom(1)
should result in, on that it be deterministic, but I have high hopes
in the general sanity and expect that UNIX people across the board
have realized that for portability the same sequence should be
returned on all platforms.

At the very least FreeBSD and Linux/GLIBC, as seen on projects.linpro.no,
agree.



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

This is a lot less useful than it could have been, as the Open Group
only mandates that:

	Like rand(), random() shall produce by default a sequence
	of numbers that can be duplicated by calling srandom() with
	1 as the seed.

But crucially leaves out *which* sequence of numbers.



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

file.

Unfortunately the thread support in FlexeLint is not quite up to our
standards of creative locking.



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

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

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

Fixes #362


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

The VCL man page documented the capturing parentheses as using $N
rather than \N which is actually used.

Fixes #359


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

Move the || true bit of invoking tclsh to the Makefile, since
missing would otherwise not pass the file name to tclsh.

Thanks to des for spotting this.


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

Drop the consistency check for health-changes, at the cost of a
slight bias[1] for hosts before, or after, then one that changed health,
according to how its health changed.

Count all failures to pick against the retry count.

Fixes #361


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

- Removed the requirement for kernel => 2.6.0. All supported
  platforms meets this, and it generates strange errors in EPEL



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

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

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

find them.



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

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

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

merge #3350 into trunk -- make tests fail if you have a long and correct search list; which my laptop has

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

Spotted by:	nkallen



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