[Top][All Lists]

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

Re: Dynamic loading progress

From: Stefan Monnier
Subject: Re: Dynamic loading progress
Date: Mon, 14 Sep 2015 08:14:06 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> 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


reply via email to

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