-------- 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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
