[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 20:09:43 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
Daniel Colascione wrote:
we should treat OOM exactly like other sorts of error.
Perhaps we should, but currently stack overflow is not treated that way.
OS signals should go through the usual Emacs event loop, right?
I'm not sure what you mean, but let's put it this way: stack overflow can occur
while in the low-level handler for an OS signal. And even if stack overflow does
not occur, if the user types C-g three times when inhibit-quit is nil, the OS
signal won't go through the Emacs event loop; instead, Emacs will invoke (signal
'quit nil).
Perhaps what we need to do is to have stack overflow invoke (signal
'stack-overflow nil), or something like that. It's a bit tricky, though, as one
needs some stack space to call 'signal'.
The standard requires runtimes reserve enough memory to throw
std::bad_alloc. All Emacs has to do is make sure control flow reaches
the C++ level.
How does this actually work, when combined with Emacs's C-level stack overflow
checking? Won't one get in the way of the other?
When we say that we want C++
exceptions to work, the Emacs-relevant meaning is that Emacs should
return always use conventional local returns, not longjmp, so that the
stack unwinding facilities of other languages (e.g., C++) work properly.
Clearly we're not doing that, at least for stack overflow and 3x C-g, and
perhaps for other cases (I haven't investigated thoroughly).
Both the Python and Java extension APIs implement high-level exceptions
with low-level state exactly the way we're talking about here, and the
result has been generally usable.
I wonder how they deal with stack overflow, and/or with OS signals.
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- 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., 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 <=
- 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
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2015/12/22
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2015/12/22