Re: Dynamic modules: emacs-module.c and signaling errors

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 25 Nov 2015 16:23:24 -0500
> 
> > I think Daniel is worried that module code will call xmalloc, and then do
> > more work that signals an Elisp error or throws a C++ exception, and the
> > module will then leak the xmalloced memory. There may be other concerns like
> > that too, but I'm not sure what they are.
> 
> I find it hard to believe that we'd follow Daniel's recommendation
> over mine.  As far as I know, he didn't give any more evidence of his
> assertions of goodness of his approach than I did (OTOH, it's obvious at
> the technical level that Daniel's approach can be layered on top of
> mine, whereas the reverse is not true, which I think should a strong
> argument in favor of following the simpler approach I advocate).

Are you talking about signaling and throwing in case of errors?  Or
are you talking about something else?

I think we should be pragmatic here.  If there's a way of having an
interface that is safe in the face of the likes of C++ exceptions,
without unduly punishing module authors, we should take it.  It sounds
like a win-win to me.

I believe we've already found a reasonably good way to handle
signaling errors and throwing.  (I will soon install the changes I
posted yesterday.)  With that in place, module code that wants to
signal an error will look very much like what we do in core in similar
situations.

Paul wants to extend these conveniences to memory allocation, and that
is what he wrote about above.  I agree it would be nice to have that.
I'm not sure I fully understand the concerns (Paul says he doesn't
understand them fully, either), but with my perhaps limited
understanding, I fail to see why the same approach -- save the
information about the Lisp error in the environment object, then
return instead of jumping, and let module-call signal -- cannot be
used to provide a convenient memory allocator very similar to xmalloc.
At worst, we will just need to teach emacs-module.c about the
"memory-full" error, that's all.

Am I missing something?