Re: Dynamic loading progress

[Stefan Monnier]

>> 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.
>> 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.
>> 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.
>>
>> Is there some other situation you're thinking of?

> Nobody is going to consider that case.

Which other case are you thinking about then?

> It'll be hard enough to get developers to properly unwind their own
> code, especially because we're only talking about a case that's active
> when things go wrong. Of course we can make non-local control flow
> work: it works well enough inside Emacs.

You lost me.

> I'm objecting to this approach because it's a bug machine, especially

What is "this approach"?

> without the Emacs Lisp and GC machinery.

AFAIK we do have the Elisp and the GC machinery available.

> It breaks C++ RAII, because there's no way the longjmp out of Emacs
> can run C++ destructors.

This seems to refer to the "point 5" above.  As mentioned it's easy to
prevent the longjmp from escaping back into the surrounding non-Emacs
(e.g. C++) code.


        Stefan