[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
From: |
John Wiegley |
Subject: |
Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc. |
Date: |
Sun, 03 Jan 2016 12:25:24 -0800 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (darwin) |
>>>>> Daniel Colascione <address@hidden> writes:
> In practice, the Lisp stack depth limits provide enough protection, and the
> risk of data corruption is too great. The existing auto-save logic is good
> enough for data recovery, especially if we run the sigsegv handler on the
> alternate signal stack (which we can make as large as we want) when
> possible.
OK, I see we have two roads, and I see where your objection is coming from.
You say, "In practice". Can you expound on your practical experience? I'm
curious if there's a real experience you've had that leads to such a strong
objection.
Also, note that other cases of error recovery leading to undefined behavior
exist in the wild: If a process uses too much memory, Linux's OOM killer will
terminate arbitrary processes in an attempt to prevent system lockup. There
are no guarantees that it will not kill something that leaves the system in an
inconsistent or bad state, since the process it kills may have been in the
middle of a critical process, and the author might not have written proper
signal handlers.
I'm inclined to leave the stack overflow protection in until it bites us;
because I know from personal evidence that having Emacs suddenly disappear
DOES bite people. I'm less sure about "undefined behavior" that I haven't
experienced yet...
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
signature.asc
Description: PGP signature
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., (continued)
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 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/03
- 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., Daniel Colascione, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Richard Stallman, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Paul Eggert, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Eli Zaretskii, 2016/01/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.,
John Wiegley <=
- 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., Daniel Colascione, 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/03
- Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc., Daniel Colascione, 2016/01/03
- Crash recovery strategies (was: Dynamic modules: MODULE_HANDLE_SIGNALS etc.), John Wiegley, 2016/01/03