[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: |
Sun, 3 Jan 2016 15:11:05 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
Daniel Colascione wrote:
It's *critical* not to violate the invariants of code.
Sure, but we are discussing what those invariants should be; they are not carved
in stone. One possible invariant is (A) "stack overflow never happens". Another
is (B) "if stack overflow happens, callers must tolerate being longjmped
through". Either invariant is reasonable per se. It is a judgment call as to
which invariant is better for Emacs. Possibly some modules will prefer (A) and
others (B).
Take the regular expression code as an example. Suppose it has unusual
worst-case behavior that can grow the stack in arbitrary ways (which I think it
does though I'm not going to investigate the details right now). One way to
address this is to rewrite the code so that it doesn't have the behavior, but
that would be a pain; the code has been that way for decades and is crufty at
this point and a lot of Emacs depends on its quirks. Another way to address it
is to use a guard page or whatever on the halfway-decent platforms that support
that sort of thing. We've chosen the latter, i.e., we've chosen invariant (B),
and yes there are problems with this approach but it beats doing nothing and it
beats doing (A) because nobody has had the time to do (A), assuming it's doable
at all.
It should be possible to replace the printfs
in this instance with calls to write(1, "message") (which will bypass
any output buffering) and restore async-signal-safety.
Good point. I did that with the attached patch to emacs-25. However, this
doesn't address the Fdo_auto_save () issue in the same neighborhood.
If a user elects to attempt auto-save in this situation, that's on him.
Sure, and Emacs already asks the user whether to auto-save in that situation, so
this should be OK already.
Ideally, we'd make autosave async-signal-safe, which will help in this
handler and in the segfault hander.
Yes, that'd be good, if we didn't lose functionality thereby.
0001-Avoid-stdio-in-SIGINT-handler.patch
Description: Text Data
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
Paul Eggert <=
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., John Wiegley, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., John Wiegley, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/04
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/04