Re: Dynamic loading progress

[Stefan Monnier]

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

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

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


        Stefan