emacs-devel
[Top][All Lists]
Advanced

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

Re: Dynamic loading progress


From: Daniel Colascione
Subject: Re: Dynamic loading progress
Date: Sun, 13 Sep 2015 19:08:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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: signature.asc
Description: OpenPGP digital signature


reply via email to

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