Re: Dynamic loading progress

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

On 09/13/2015 06:58 PM, Stefan Monnier wrote:
>>>> 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.
>    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. 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.

I'm objecting to this approach because it's a bug machine, especially
without the Emacs Lisp and GC machinery. It breaks C++ RAII, because
there's no way the longjmp out of Emacs can run C++ destructors. Rust
cleanups, and lots of other runtimes are similarly broken. You're asking
developers to cope with Emacs deciding simply never to return from most
module API calls. That's okay for Emacs internals, but it's very awkward
for code having to talk to Emacs.

There's no need to do it that way either. Storing the exception
information thread-locally (which means globally unless we ever actually
get threads) works with C-ABI semantics, is easier to reason about for
developers not used to Emacs internals, and provides just as much error
information.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]