Re: Dynamic loading progress

[Daniel Colascione <dancol@dancol.org>]

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

Why are you so insistent on using non-local exits for error handling?
Representing errors more conventionally is cheap. If there's even a
small chance that I'm right about the safety and maintainability
advantages of using purely local exits, why not err on the side of
caution? AFAICS, there's no advantage to using non-local exits and
plenty of risks.

On 09/14/2015 05:14 AM, Stefan Monnier wrote:
>> Yes, but the whole point of the module system is to access non-Emacs
>> libraries,
> 
> But the issue only comes up once these non-Emacs libraries call back to
> Emacs functions (i.e. step 5 in my example).  So only those calls need
> to be protected somehow from non-local exits.

Calls back to Emacs functions will be fairly common, because modules use
these functions to manipulate Emacs data on behalf of their own callers.
Any of these functions can quit. What you're imagining will be a rare
case will in fact be common.

I also don't think it's correct that the Emacs-specific module code will
work properly in the presence of modules. You're supposing too much
patience and knowledge on the part of third-party module authors who'll
want to provide bindings not only for Emacs, but for other systems as well.

>> and these libraries will have its own resource tracking
>> systems, which won't integrate with the Emacs GC core.
> 
> Right, just like the libraries we currently link to from core Emacs
> (libxml, libgnutls, libX, ...).   They *very rarely* call back to
> Emacs functions.
> 
>> Imagine if you had to individually arrange to call free on both the
>> success and error paths for every string you wanted to allocate ---
>> that's what life will will be like for module authors.
> 
> No.  Only for those who choose to use use manually-managed data.

Who will be common, because the entire point of writing modules is to
work with the _non_-Emacs world. I can imagine one module that has both
non-trivial calls back into Emacs and quite a bit of internal state in
suitable for management with Emacs primitives. It's called Python.

Modules aren't going to be limited to small data-centric thngs like
libjpeg, and we shouldn't design the extension system in a way that
discourages more complex kinds of integration.

>> I don't imagine most modules will be using Emacs GCed resources for
> 
> I do.
> 
> And I think we should encourage them to do so.  For that reason we want
> to add finalizers, for example.
> 
>>> 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.
>> I agree that it's possible. I don't agree that it's easy.
> 
> Of course it is.  We already do that in Emacs's core with things like
> safe_call.

safe_call blindly suppresses errors. Errors from module-invoked
functions to propagate normally from the perspective of surrounding Lisp
code.


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