On 09/29/2015 11:56 PM, Herring, Davis wrote:
>> We still have to catch the longjmp.  The setjmp *is* the barrier as
>> far as Fsignal and Fthrow are concerned.  See unwind_to_catch().
> 
> The "struct handler" is the barrier: it's a detail of the current implementation that it contains a jmp_buf (that is always used).
> 
>> Unless you're proposing to replace unwind_to_catch itself with
>> something that signals "locally" for the duration of the callback.
> 
> I think by "locally" you mean "by normal function returns only".  That's not my idea, which is basically to (conditionally) replace
>   sys_longjmp (catch->jmp, 1);
> with
>   catch->hook ();
> 
> where (according to my straw-man code) catch->hook was populated by the call to env->error_handle.  It's still a non-local transfer, as is necessary for the existing calls to unwind_to_catch to possibly work.
> 
>> AIUI, that's exactly what Daniel and Philipp *don't* want!  They want
>> to avoid having the client contain error handling code for Lisp at
>> all, instead managing it behind the API in the Emacs module
>> implementation, and thus making it idiot-proof.
> 
> I'm aiming more for idiot-resistant, without the complexity (and overhead) of wrapping every call into Emacs to protect the caller.  In other words, it's a way to recover control (like they want) without significantly extending the "unsafe" interface (which Stefan wants).
> 
>> Which is what Daniel and Philipp want, and which is what I think is a
>> horrible idea, akin to using `ignore-errors' in basic Lisp functions
>> like `car'.
> 
> But it's not ignore-errors: in my example, the error does propagate,
> but as a C++ exception rather than a longjmp.  Some easy RAII would
> let you reliably get the error_handle and the matching error_unhandle
> in one shot (avoiding the possibility of forgetting it, as I did in
> my example!).  In the trivial case that you just want destructors to
> be called and the error to propagate back into Lisp, you could avoid
> an explicit try-catch on each module entry point with a wrapper
> function template.

One practical difficulty of this scheme is that we would have to build
Emacs itself with exception unwind information. (Since the default
Itanium ABI behavior is to abort if we try to unwind through a stack
frame for which we don't have unwind information.) I don't think that
would be easy to pull off in the general case, and I don't think it's
possible in advance to predict what information we might need to allow
stack unwinding to proceed. This scheme leads us further into
ABI-dependence. I'd prefer longjmp to a system that required us to let
C++ exceptions (with what libstdc++?) propagate through arbitrary Emacs
frames.