Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Yuri Khan]

On Mon, Dec 21, 2015 at 5:00 PM, Paul Eggert <address@hidden> wrote:

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

On the Emacs side of the module API, Emacs should not have to
implement any special treatment for C++ exceptions. (Because if it
does, where do we draw the line? Should Emacs then handle any other
languages’ exceptions?)

A sane approach is to have a C-only API, and module developers who
want to write modules in other languages will devise their own
wrappers/adaptors to make interfacing with Emacs easier and less
error-prone. As part of its contract, such an adaptor shall prevent
any exceptions from crossing the module boundary.

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

I’m lacking full context here; do you mean not using nontrivial
destructors *at all*? This would amount to banning C++ as a possible
module development language, as nontrivial, deterministically invoked
destructors are its very essence.