passthrough works

[Poul-Henning Kamp]

I think we can declare the "hole through" milestone reached now.
I can see both www.cnn.com and www.freebsd.org in my firefox.

The HTTP header processing is very minimal and it won't take much
for a client or server to confuse varnishd at this point, but in a
controlled setting things survive.  (I've stopped leaking backend
connections but probably not memory yet).

To me this is an important milestone because it allows us to work
on multiple aspects of varnishd in parallel now, without getting
in the way of each other.

The VCL language definition and implementation can now progress at
least as far as header inspection and modification (including
URL rewriting).

At the same time, the actual cache implementation can proceed in
the background.


But I'm starting to reconsider the "unified" VCL idea again.

With the "unified" VCL execution where the object lookup and fetch
are explicit VCL actions, we need to park a worker thread on each
request because in essence that means VCL can sleep.

This implies that splitting the worker threads into "senders" and
"receivers" is of no benefit and instead we will just have one
(finite) pool of worker threads.

That again implies that in order to limit how hard we will hit
the backend we need to make backend-connections a pooled resource
which worker-threads may have to wait for.

Which again means that we could have a "pile-up" where all the
worker threads are waiting for backend connections and none of
them service the cached requests.  Adding more workerthreads
will not solve this issue if the backed is very slow or similar.

Overall, this is not a situation I'm happy about, parking a thread
for each request waiting for a resource is pretty much exactly
what I do not want to do.

One real solution is to checkpoint the VCL execution so that we
don't have on-stack context while doing things which might sleep,
but this is somewhat complex in the compiler because a full path
analysis and tree-pruning needs to be performed and the result of
that can be quite explosive in size, if for instance "fetch" is
called conditionally in a subroutine.

Another real solution is to make VCL execution restartable, that
is less complicated, but still in the ugly-bugly category.

And finally there is the option of making the sleeping actions
terminal in the VCL language, so that "fetch" means that the
VCL function excution stops at that point.

That forces us to give up the "a single main function",
model and instead use several VCL functions:

Legend:
	[VCL-function]
	<sleeping action>

                [pre-lookup]
                     |
                     |
                     |
                 <lookup>
                   /  \
                  /    \
                 /      \
              [hit]    [miss] 
                /\      / 
               /  \    / 
              /    \  /
             |    <fetch>
             |       |
             |       |
             |       |
             |   [post-fetch]
             |    /
             |   /
             |  /
           <finish>

I'm particularly worried about introducing complexity in VCL so
your input on this, (does this diagram even make sense to you ?)
would be most appreciated.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.