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

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

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

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

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

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

developer compatible.

POSIX, no surprise, doesn't really tell what should happen to a threaded
process which forks and consequently implemenations vary somewhat,
from Solaris which seems to Do The Right Thing, via Linux where it
works "most of the time" and to FreeBSD which more or less actively
sabotages any such attempt.

Grin and live with it...



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

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

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

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

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

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

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

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

It's general enough to find other uses, but right now it's only for
the manager process.



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

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

spurious first entries.



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

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

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

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

as well allow their manipulation also when the child is not
running.



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

Keep track of all loaded VCL programs in the manager and tell the
child to load them via VCL.

Don't start he acceptor thread until a "start" command cones down
the CLI.

XXX: Right now we leak stuff when a VCL program is dicarded



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

Take default_vcl out of heritage.

Keep track of all compiled VCL files and delete them at
exit.

After starting child, use CLI to load all vcl programs
and then issue "start" via the CLI.

In the cacher, don't start the acceptor until we get
a start command.



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

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

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

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

Add mgt_cli_askchild() function to poke the CLI interface to
the child.

Use it to ping the child every second.


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

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

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

The first line of the response has a fixed format ("%-3d %-8u\n")
and consequently fixed length (CLI_LINE0_LEN == 13).

This makes parsing responses more efficient.  Add a function
in common_cli to do so.




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

cache process again.


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

impossible.



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

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

Placed a new sbuf_clear at a more strategic place. It got cluttered when a host left without SessionClose of SessionReuse.

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

Got a workaround for IP adress fetching. If we connect logger while Varnish is running, we won't catch the IP from SessionOpen since it's already done that. Workaround is to catch the IP from SessionReuse if IP of session is NULL

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

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

fetch it.


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

Not as useful as it will be yet, see ticket 22



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

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

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