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

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

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

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

When -d(ebug) is specified we fork before calling daemon.

The parent process becomes a miniature cat(1) program which connects
stdin/stdout with the management process stdin/stdout.

It also knows that SIGINT should be passed on to the management process
in order to make it DTRT.

Any other cause of death for this "debugger" process will (once I
teach the CLI about it) not affect the running varnish and therefore
it will be possible to start varnish in debugging mode, tweak things
a bit and CTRL-D and leave it running in the properly daemon(3)'ed
background.

The reason for this rather complicated bit of pipework is that we
can not call daemon(3) once we have started any threads (only the
calling thread survives) and we would loose our parent relationship
to the cache process also.




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

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

Simplify the logic here while we're at it.



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

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

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

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

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

directly instead of libevent.

Degeneralize the header reading code in cache_http.c which seems to
be cleaner anyway.

An #ifdef at the top of cache_acceptor.c selects which implementation
you want: libevent or kqueue.



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

and eliminate the per-workerthread event engine entirely.



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

in the current stack corruption I see, but we might as well avoid
using it where we can:

Don't engage the eventengine when we talk to the backend, just call
read(2) directly.



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

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

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

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

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

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

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

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

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

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

http header which we can use to build the object headers in.



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

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

and define this as the "start of request timestamp".

Define "end of request timestamp" as when we are ready to transmit
HTTP header back.

SHMlog the start and difference between start and stop with ReqServTime
tag.

Keep track of idle sessions using CLOCK_MONOTONIC to avoid trouble
here should our clock get stepped.




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

Added some more toying with the data. All is still a mess, and I am not sure of structure yet. PHK is also doing changes in areas that will be needed.

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

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

	{Rx,Tx,Obj}{Request,Response,Status,URL,Protocol,Header,LostHeader}

And log http header munching accordingly.



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

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

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

we checked if the request is a GET long after we should have.



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

Eliminate the header index from http_SetHeader() which is no unused.



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

we don't get two confusing batches of TxHeader in the sessions logentries.


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

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

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

no need to waste time printf'ing in this case, and no need to waste workspace.


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

have space for composing the reply as well.

Without this fix, the entire workspace could be filled with pipelined
requests and we would have no space to compose the reply.



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

NCSA-style (common / combined) logs.

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

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