emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Dynamic loading progress


From: Herring, Davis
Subject: RE: Dynamic loading progress
Date: Wed, 30 Sep 2015 06:56:33 +0000

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

Davis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]