Re: Dynamic loading progress

["Stephen J. Turnbull" <stephen@xemacs.org>]

Davis Herring writes:

 > What if we avoid the longjmp call rather than catching it?  Define a
 > (thread-local) signal-raising hook which is also a specpdl barrier.

We still have to catch the longjmp.  The setjmp *is* the barrier as
far as Fsignal and Fthrow are concerned.  See unwind_to_catch().

Unless you're proposing to replace unwind_to_catch itself with
something that signals "locally" for the duration of the callback.
That seems like a very dubious idea to me.  Rather, as Daniel has been
at pains to say, it's a shame Emacs didn't do that in the first place,
as more recently designed languages have managed to do.[1]  So if
we're going to provide a "no nonlocal exit" unwind_to_catch() for
modules, let's use it for Emacs itself, too!

 > A C++ client, for example, could write

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.  Perhaps with some
concessions for setting handlers to the DIYers, but there would alway
be a safety net.

I think this is an illusion, and a dangerous one, for code that is
complicated enough to provide a callback interface that accepts Lisp
functions.  *Especially* if written in crash-prone languages like C
and C++.

 > We might be able to avoid even that by putting the handler into the
 > emacs_env,

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


Footnotes: 
[1]  Amusingly enough, even those languages don't always manage to
avoid longjmp entirely: Python 3.5 still has two instances of longjmp,
one in Modules/fpectlmodule.c, and the other in Modules/readline.c.