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.

(via objcore method) and refer resultant empty persistant segments.

it refers to.

one segment open at a time anyway.

Add a "sync" debug command

testing and debugging.

should be on.

Reminded about again by:	Ralph Corderoy <ralph@inputplus.co.uk>

actually makes sense...

Spotted by:	Ralph Corderoy <ralph@inputplus.co.uk>

from git.

Use strcmp and not == for comparing strings

Typos in documentation, thanks to Camiel Dobbelaar for spotting
these.

If varnishd is compiled with -DDIAGNOSTIC and run with -x dumprst
(previously -x dumpmdoc) it will dump the paramer definitions in rst
(previously mdoc) format, suitable for including into the varnishd
reference documentation.

systematic footing.

debug pipe.

VCC expects an ID, and complains if it is not on the list of
valid values.  The value is passed as a "const char *"

More and better error messages from vmod.py