[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Mon, 21 Dec 2015 03:00:25 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]