Re: Dynamic loading progress

[Stephen Leake]

Stefan Monnier <address@hidden> writes:

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

I think Daniel's point is that most module developers will not be aware
of this issue, and will be totally lost when it occurs.

In addition, how many libraries document whether they are "longjmp
safe"? I suspect that actually depends on compiler options, so it's up
to the packagers to ensure it.

Imagine someone used to writing Java code, with the attitude "the
language is totally safe, I don't need to worry about details"; now they
try to write an Emacs module, calling out to Java code all over the
place. Chaos ensues, and Emacs gets another bad wrap as "unusable".

So if the Emacs module API can be made to support those developers, it
would be a good thing.

I think his point is valid, although it would be nice for expert module
developers to be able to bypass the "safe call" if it becomes a
performance issue.

I don't think we can make writing an Emacs module as easy as writing a
Java class, but we should consider doing as much as we can to make it
easier/safer for the novice.

On the other hand, being forced to handle an exception instead of
remembering to check a status code is a proven win. So perhaps there is
a way to make all module developers aware of this issue; a well written,
short "module developer's checklist" would help here.

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

Some module authors won't realize they've chosen that.

-- 
-- Stephe