[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
- Re: Dynamic loading progress, David Kastrup, 2015/10/02
- Re: Dynamic loading progress, Davis Herring, 2015/10/08
- Re: Dynamic loading progress, Stephen J. Turnbull, 2015/10/08
- RE: Dynamic loading progress,
Herring, Davis <=
- Re: Dynamic loading progress, Daniel Colascione, 2015/10/08
- Re: Dynamic loading progress, Stefan Monnier, 2015/10/08
- Re: Dynamic loading progress, Philipp Stephani, 2015/10/08
- Re: Dynamic loading progress, Stefan Monnier, 2015/10/08
- RE: Dynamic loading progress, Stephen J. Turnbull, 2015/10/08
- Re: Dynamic loading progress, Davis Herring, 2015/10/08
Re: Dynamic loading progress, Aurélien Aptel, 2015/10/08
Re: Dynamic loading progress, Tom Tromey, 2015/10/08