Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mo., 14. Sep. 2015 um
03:58 Uhr:

> >>> It's not possible to skip frames in module code using longjmp, so
> >> Why not?
> > Because most C code isn't expecting to be unwound.
> > Forcing non-local flow control on module code is completely
> > unacceptable.  Emacs needs to return with an error indication set.
>
> Hmm... I'm still not sure what's the issue.
>
> AFAICT, the only odd case I can think of is the following:
>
>    1- Emacs calls some module code via the new API.
>    2- This code (which is Emacs-specific) will know about Fthrow.
>

Even if it knows about non-local jumps, in many cases it can't do anything
about them except wrapping them. For example, longjmp is illegal in most
C++ programs (and probably in most other languages as well).


>    3- It may call some non-Emacs-specific code from some other library.

   4- This non-Emacs-specific code calls back to some Emacs-specific
> function.
>

Step 3 and 4 can be left out. The issue only requires that the plugin
contains some code that is not suited for longjmp; e.g., all C++ code, no
matter whether written specifically for Emacs or not.


>    5- This Emacs-specific function calls Fthrow/Fsignal.
>
> Where the problem only shows if/when we reach point 5.
>
> This problem can be handled between 4 and 5 by using an appropriate
> internal_condition_case.
>

Partially yes. internal_condition_case with a Qt handler can indeed catch
all signals, but this invocation is only possible from Emacs C code (using
internal_condition_case), and the fact that signal and throw use longjmp is
an implementation detail anyway, so the catch-all code needs to be inside
the module code.