Someone should triple-check that it is indeed safe.

Submitted by:   Frederic Lecaille <flecaille@haproxy.com>

any more.

It turns out people are really attached to their varnish.params file.

See `git grep PROXY -- bin/varnishd/mgt/mgt_main.c`.

that should not happen.

would give subsequent esi-includes the wrong vcl.

not need it (acceptor, h2_sess)

store more stuff in it.

This reverts commit 5b6a4e56.

The moment we unlock the oh, another thread could rush req

Partially undoes f35b86bc

Huge thank you to @mbgrydeland for spotting my mistake

and polish the output formatting by reordering

Ref #1799

Ref #2743

see 11 lines down

req's on waiting list do indeed hold an objhead ref (req->hash_objhead),
so the condition for the while loop in hsh_deref_objhead_unlock will
always evaluate to false.

This gets rid of the needless rushing code and replaces it with an
assert.

avoid the LONG_MAX check.

Simplify the !busy cases

Inspired by:	#2856

Use req->hash_always_miss directly

Inspired by:    #2856

Refactor the hit-cases

Inspired by:	#2856

Move successful loop termination out of the loop.

Inspired by:	#2856

Make use of the new hsh_deref_objhead_unlock() in HSH_Lookup() to reduce
the number of times the objhead mutex is taken during cache hits.

Split hsh_deref_objhead() into two parts, with the new
hsh_deref_objhead_unlock() function expecting a locked objhead reference
on input.