[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 10:15:02 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
Eli Zaretskii wrote:
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?
Yes and no. As I understood it, that old conversation was about functions that
explicitly signal or throw, and it's safe to assume that EQ, NILP, etc. won't do
that. The new conversation is about running out of memory, which is a different
form of non-local exit. There may be other forms, such as operating-system
signals (I don't recall exactly).
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.
This wouldn't suffice for these other non-local exits, I think; at least, not as
currently constructed.
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.
There should be workarounds for that. Surely the C++ community has run into this
problem and has solutions. If we want to support C++ modules, we need to employ
them.
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,
Why bother? If C++ exceptions are supposed to be caught by the C++ module in
question, why does Emacs need to worry about C++ exceptions that are not caught?
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?
It uses a different model at the C level from what one sees in Elisp, or from
what one normally sees in C for that matter. I don't feel that I will really
understand the model unless I see some actual modules that do function calls and
exception handling; but it's hard to believe that a model that does silent
returns and that defers returns until later and that records some returns but
not others will be problem-free. Wouldn't it be simpler to have a module invoke
analogs of 'condition-case' and/or 'catch', and to dispense with the
funcall_exit stuff?
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Philipp Stephani, 2015/12/19
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/20
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Philipp Stephani, 2015/12/20
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/20
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/20
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/20
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Yuri Khan, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
Paul Eggert <=
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Philipp Stephani, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/21
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/22