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
situations.

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.