Ah cool ... setjmp / longjmp

[Baker]

I've seen that setjmp (host_abortserver) in the code in Host_Frame many times.

But I never knew what it did, therefore left it alone and ignored it. I'm doing some "deep" "homework" and writing some command interpreter type code and encountered a situation that would be really hard to handle "non-fatally". I looked at PF_error and Host_Error. And then investigated that longjmp ... discovering it essentially re-routing and aborting a call stack kinda of like try .. catch.

I was wondering how to sensibly recover from an annoying error without terminating execution. The error itself isn't such a big deal, but get nested in several function calls ... well ... it would require a hell of lot of code and busting of for-loops a such.

Obviously setjmp/longjmp have to be used with extreme care, the circumstances should be exceeding rare. But it exists! Reading the docs, I'm not sure how or if it recovers the memory or the call stack so it seems a bit dodgy though.

Without really understanding that longjmp statement was, I previously also had an incomplete understanding of Host_Error.

[taniwha]

Stack memory is indeed reclaimed, every byte of it. However, any memory allocated otherwise that's referred to only by local pointers will be lost. setjmp/longjmp work by setjmp saving the stack pointer and return address (and probably a few registers) and longjmp restoring those saved values. This is why both all stack memory is reclaimed and setjmp/longjmp are very fast.

Two main problems with setjmp/longjmp are the already mentioned issue with non-stack allocated memory and the local variables of the function that called setjmp potentially getting trashed. Also, there is one danger (easily mitigated): calling longjmp from a function not exclusively in the call tree of the function that called setjmp will mess up the stack and cause all sorts of bad things (for the one jump record, of course).

[Baker]

So has to be the root of where you want to say "Ah, nevermind all those functions we just called."

[Spike]

avoid it if you can. bypassing the function returns means you can end up bypass free() calls, and/or result in half-configured data structures.
It has all the issues of try/catch combined with the fact that you cannot easily catch exceptions in code that actually needs to catch them.
So anything that can culminate in a Host_Error needs to ensure that it is written well enough that it can be re-execed without simply failing instantly once again. Which is why much of the code simply uses Sys_Error instead.

[Baker]