[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: 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.

Attachment: 0001-Avoid-stdio-in-SIGINT-handler.patch
Description: Text Data

reply via email to

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