|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |