Workspace overflow handling

[Poul-Henning Kamp]

--------

I've spent a lot of time pondering this over the years, and as
always with hard problems, there are no easy, cheap and correct
solutions, and you may not even get to pick two out of three.

When I designed the "sbuf" API many years ago in FreeBSD (also
known as VSB's in Varnish) I had concluded that the main
"threat" of good robust error handling was that it munged up
the source-code with pointless verbiage and boiler-plate.

The result was the "latch-and-report" scheme of sbuf/VSB, where
you can carry on as long as you like after a failure, but nothing
(bad) is going to happen, because the error-latch is already set.

I spent some time, before getting distracted by other more important(?)
hackery, giving struct http such a latch-and-report mechanism,
except the latch is actually on the workspace associated with
the http structure.

Once completed, that work should pretty much take care of compiled
VCL code because we can simply test when the VCL method returns and
fail the transaction there.

VMODs and VRTs need to be more alert obviously, but that is much
more manageable.

I don't belive much in your "just double the allocation with unused
VM" idea, first because there is no guarantee that the number two
is magic and big enough, so we'd still have to check all over the
place, and second because the necessay management of map/unmap is
a needless complication.

So summary:  I think we all agree on the end result, and I belive
that mark/report is our main means to get there, but there is
so much code to hack and so little time...

Poul-Henning

PS: And no, I'm not going to rewrite Varnish in Rust

-- 
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.