[Top][All Lists]

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

Re: Dynamic loading progress

From: Stefan Monnier
Subject: Re: Dynamic loading progress
Date: Mon, 28 Sep 2015 15:20:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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

There's nothing else none can ever do about them other than
wrapping them.  So the fact that they can only wrap them is not
a downside of some alternative.

> For example, longjmp is illegal in most C++ programs (and probably in
> most other languages as well).

Most Emacs modules will be written in C, methinks.  For those written in
other languages, since the API is expressed in C, they'll have to
accommodate the interaction with this C API, yes.

If they want to add a whole layer that wraps every function call in an
internal_condition_case, that's fine by me.

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

That's a problem for the C++ code, not for Emacs's C-level module API.

> 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),

Clearly, we'll want to export it to the modules as well.


reply via email to

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