Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert]

Eli Zaretskii wrote:
> 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.

> or should place
> comments there to the effect that we disregard that possibility (and
> maybe augment the comments in lisp.h saying that stack overflow is the
> only allowed reason for non-local exits).  Which one do we prefer?

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.

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

If this simplification cannot be done, one possible workaround would be to say 
that C++ modules should not use nontrivial destructors. This would be a 
different way to let us simplify emacs-module.c significantly, albeit a way that 
is less satisfactory for C++ modules.