[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Daniel Colascione
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Mon, 21 Dec 2015 22:53:44 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 12/21/2015 10:44 PM, Paul Eggert wrote:
> Daniel Colascione wrote:
>> It's programmable in Lisp. Lisp stack overflows shouldn't kill Emacs.
>> I'm suggesting that we shouldn't care about *C* stack overflows.
> The Lisp stack *is* the C stack. There is just one stack, which can
> overflow in module code or in Elisp interpreter code (or in library code
> or whatever). Whatever technique is used to detect Lisp stack overflows,
> should be usable to detect stack overflows in module calls.

It's true that we have a unified stack, but that doesn't mean we have to
treat both Lisp and C stack frames identically. My chief problem with
the current stack overflow detection is that it's completely
asynchronous: we can longjmp on *any* stack enlargement, even in the
middle of a sequence of operations that can't normally be interrupted. A
much more limited approach, where we probe the stack in Feval and
longjmp only in safe positions, but would work as well for lisp, but
would prevent our trying to recover from inherently unrecoverable

But why bother? We have max-lisp-eval-depth to prevent runaway
recursion. Whenever I've written clowny overly-deep code, I've always
hit that limit, or max-specpdl-size, first.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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