these functions.

The [v]asprintf() functions are convenient shorthand, but suffer from
a number of problems, portability, cornercases and performance being
the most relevant to Varnish. 

Static buffers on the stack (see [v]bprintf macros, or sbufs (vsb)
are always better choices for us.



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

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

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

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

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

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

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

new sessions as such.  If we get no request in the session_linger
window, we punt the session over to the waiter, in order to not
tie up a worker thread longer than necessary.

This makes the session_linger a more important paramter to tune/get
right, but should also reduce our vulnerability to certain DoS attacks.



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

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

to the client absconding the TCP connection.

This comes to the fore on Solaris, where not only systemcalls which
push data through sockets (read,write,select...) return these errors,
but also socket-state calls (setsockopt, ioctl, fcntl) do.

Root cause of trouble in #626 & al.



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

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

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

and working, and panic with a somewhat usable message if not.

PS: And boy, are you screwed if my test sneaks though a kernel bug...



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

the features listed on the present platform



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

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

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

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

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

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

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

Don't update the pollfd state from the pipe, until we have dealt with
all sessions.

Strongly assert the pollfd state everywhere.



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

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

spurious test-failures if peoples DNS servers lie to them.

Fixes #356



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

now.



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

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

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

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

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

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

Fixes #644


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

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

Mention this in man page.

Update param list in man page.



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

When we do a lookup, we first try without the lock, if this gives
us a refcnt==0 objhead, we try again, with the lock.

When we deref an objhead, we would decrement the refcnt, holding oh->mtx,
then lock the critbit-lock and remove it from the tree.

It might be possible for a locked lookup to find an oh we just decremented
the refcnt off, and we did not check for refcnt==0 in that case.

Fix this, by removing the oh from the tree, holding the critbit-lock,
before decrementing the refcnt.  This way, a locked lookup can never
find a refcnt==0 oh in the tree, and the unlocked lookup still catches
this with the refcnt==0 check.




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

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

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

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

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

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

"Connection: close" or if a HTTP/1.0 backend does not send "Connection: keep-alive".

Fixes	#495



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

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