Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[John Wiegley <jwiegley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

>>>>> Daniel Colascione <dancol@dancol.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]