[Top][All Lists]

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

Re: Dynamic loading progress

From: Philipp Stephani
Subject: Re: Dynamic loading progress
Date: Mon, 28 Sep 2015 15:12:28 +0000

Stefan Monnier <address@hidden> 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

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.

reply via email to

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