preceeding verbatim bytes, we would not emit the gzip header
until after the included file.

Instead force the gzip header out as SKIP and inject a synthetic
one where needed during delivery.

Optional libedit support to varnishadm.  No saving of history or
completion yet.

workspace either.

runs into trouble when we reset the workspace as part of ESI:include
processing.

Fixes: #861

maintain proper ordering.

minimum demanded by the system.

this works better with Solaris

a smarter compiler than GCC could have seen through.

Fortunately there is a backstop, so worst case a request would
just fail.

Spotted by: Erik
Missed by: phk, twice

Now it does.

The lock order is lru->exp lock, so that the timer_index
can be safely examined while holding only the lru lock,
eliminating the need for the separate OC_F_ONLRU flag.

The critical trick is that in EXP_Touch() the lru_lock
is sufficient:  We just move the object around on the
lru list, we don't add or delete it.

This hopefully reduces lock contention on these locks.

process.

whatever storage we have put the object into.

caught it, he would always say "Just checking if you were
paying attention".

I guess Erik Inge Bolsø was :-)

ones that later may find usage in a separate silo-maintenance utility.

Experience shows that 2ms is a better value for thread_add_delay.
This is high enough to prevent thread pileups and low enough that
we do not run into as too few thread problems at startup.

Commit the code that prevents all the evils mentionend in the
previous commit message (see tests/p00007.vtc)

So imagine an object during fetch, where we have allocated
the storage for the object structure, the persistent silo
gets synced, so the data ends up in the next segment, and
then we crash before that segment gets synched to silo.

On restart the object looks good, until we try to access
its storage... *bewm*

This is a stopgap, that catches such objects and neuters
them, using a set of paranoid sanitychecks we should
employ in any case.

There still is a relevant hole: As above, but after
the restart we manage to write a new segment before
the initial object is accessed, and it happens to
have a storage structure just the same place (not
unlikely at the beginning)

We do not crash in this case, but deliver wrong content.

Did I ever mention that -spersistent for all practical
purposes is a filesytem ?

Remove the aim_nobj, it has been found not useful.

Remove pointer from persistent.h, it shouldn't contain any.

Document debug.persistent, it will be useful for debugging.

Exercise it in testcase.