Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Eli Zaretskii <eliz@gnu.org>]

> Cc: aurelien.aptel+emacs@gmail.com, p.stephani2@gmail.com, dancol@dancol.org,
>  tzz@lifelogs.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 21 Dec 2015 03:00:25 -0800
> 
>     Then we either cannot use them in emacs-module.c,
> 
> The lisp.h functions are no different from any other functions in this respect, so this is not a lisp.h problem. Stack overflow can occur with any function call, even functions defined within emacs-module.c itself. 

This discussion started so long ago that we've lost the perspective,
and its main point is no longer in our sights.  Let me remind that.

A long time ago in a galaxy far, far away, I wrote in
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg02190.html:

> > . Why don't some functions use any of these macros, although they do
> >   call Emacs functions?  Examples include module_make_integer (calls
> >   make_number), and module_make_user_ptr (calls make_user_ptr).
> >
> > . It seems like emacs-module.c assumes something about certain Emacs
> >   functions, and based on that decides not to use these macros even
> >   when calling those Emacs functions.  For example, module_vec_get
> >   calls ASIZE and AREF, but doesn't use the MODULE_HANDLE_* macros.
> >   Evidently, it assumes that neither ASIZE nor AREF will ever signal
> >   or throw.  But isn't that a fragile assumption?  The
> >   implementation of internal Emacs functions is subject to change
> >   without notice, and it would be a maintenance burden to have to
> >   analyze upon each such change whether emacs-module.c needs some
> >   augmentation.

And you replied in
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg02270.html:

> While that's true in general, I think some exceptions are OK. E.g., it's OK if emacs-module.c assumes that ASIZE is a simple access function or macro that doesn't throw signals. If we actually changed ASIZE to throw signals, there's a boatload of other code we'd need to change as well, and changing emacs-module.c wouldn't add much more to the maintenance burden.

Phillip's comments that you reverted were the logical consequence of
the apparent conclusion we drew from the above exchange: that it was
okay to assume these functions/macros cannot throw signals.  Are you
now saying something different from what you said back then, i.e. that
we cannot rely on any function/macro from lisp.h to be signal-safe?
If so, we should add the necessary protection, in the form of calls to
MODULE_FUNCTION_BEGIN, to emacs-module.c functions that until now
relied on those lisp.h functions/macros to be safe.

> If emacs-module.c is incompatible with stack overflow detection, then we should put a FIXME comment in emacs-module.c saying so, as this is a recently-introduced bug that should get fixed. I did this just now.

> Perhaps someone with C++ expertise can chime in and say how C++ programs are expected to deal with stack overflow. Whatever mechanism is used, Emacs should be using it.

I have no idea how (or even if) C++ code can cope with stack overflow,
except by leaking all the objects that were alive at the point where
we detected stack overflow.  AFAIK, proper C++ exception handling
requires non-trivial amounts of stack space that is not available when
there's stack overflow, where you have at most a single guard page to
work with.

> Come to think of it, there must be a better way for emacs-module.c to deal with C++ exceptions. The current approach is complex, confusing and error-prone. If emacs-module.c or the Emacs exception-handling mechanism really needs to be rewritten in C++ in order to catch C++ exceptions nicely, then somebody with C++ expertise should do that. (Optionally, of course; it should be OK to have a C-only Emacs that does not worry about C++ modules.) If done well, that should simplify the module interface considerably, for both C and C++.

I think there is some misunderstanding here, or some confusion,
perhaps mine: emacs-module.c is not supposed to deal with any C++
exceptions.  C++ exceptions are supposed to be caught at the C++
level, below emacs-module.c, and handled there.  An exception that
isn't caught will be recorded and will cause all the subsequent calls
to Lisp or to emacs-module.c function to fail, until we return back to
the Lisp interpreter that called the module function.  But it will not
cause any C++-specific trouble.

What emacs-module.c does with non-local exits of _any_ kind is record
the first occurrence of such an exit, and silently return to the
caller, thus allowing the C++ objects on the stack to be destroyed
normally.  IOW, it defers the exit until internal--module-call is
about to return.  What problems do you see with that which cause you
to think it's error-prone, let alone dysfunctional?