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

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

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

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

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

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

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

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

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

have a <sys/queue.h> that differs in small but important details from what
we expect.  Replace our "queue.h" (which was taken from NetBSD) with a new
"vqueue.h" which is based on FreeBSD's <sys/queue.h> with the debugging
taken out and a "V" prefix added to everything.


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

use <sys/queue.h> instead of our own if present.


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

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

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

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

A couple of XXX comments
Some returnvalue asserts
Some pdiff() uses
Change WRK_Flush() to return unsigned



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

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

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

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

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

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

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

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

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

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

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

The id argument is a file descriptor, so it should be typed "int".
We must have a fmt argument.
Use pdiff.


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

signed.  pdiff() makes sure we never get a negative value.


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

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

nitpicking to new heights:

Make sure VRT_int_string() has enough room and assert that this was the case.



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

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

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

any object with heap_idx == 0.



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

object on deathrow.



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

for the client to reply on the internal CLI pipe.



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

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

varnishd can use to decide if a backend state can be shared between
multiple VCL programs.
 
Originally the idea was to calculate a strong hash over the tokens 
which define the backend.  

Considering the relatively short lengths of backend declarations
and the infrequency of comparisons, we have opted for an extremely
weak hash instead:  We simply output the space separted tokens as
a string.
 
The net change in code for simple backends is marginal, but for
complex backends this will be a lot simpler to implement.



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

cause Really Weird Problems if you really provoke it.

+++ Redo from start +++

LRU processing is only relevant for objects which are in the cache and
on the EXP binary heap so we merge the LRU functionality with the EXP
code in order to share locks and object reference counts.

Another thing we overlooked in the first implementation is that the VCL
callout for LRU should be able to examine the client information for
the session which tries to push stuff out, so that QoS/DoS issues can be
considered:

	sub vcl_dicard {
		if (client.bandwidth > 10 mb/s) {
			keep;
		}
	}

(which sort of indicates that "error" should be a legal action as well)

To enable this, pass the session into the stevedore when we try to
allocate space and temporarily substitute the target object for its
own object while we call vcl_discard().

The outcome of an attempt to make space can take three values, did,
didn't and couldn't.  In the latter case there is no point in trying
again and again, in particular if the cause is incurable, such as
the requested size being larger than the storage.   We still need to
handle failure to allocate storage for that case rather than core dump.

When looking for targets to nuke, we only consider objects on the
binheap which has reference count of 1, objects with higher reference
counts would not free space.

We take prospective targets off the binheap, but retain their
refcount, and tag them with a magic marker while we ponder their
destiny.

It is quite possible that another session could pick the object up
via the cache while we do so, and therefore attempts to update the
ttl or shift them in the lru chain must ignore objects which has
the magic marker.  If the object is kept, the updated ttl will
automatically take effect when we reinsert it in the binheap.



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

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

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

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