Re: [Chicken-hackers] [PATCH] "deep-stack" option, declaration and build-mode

[Felix]

>> Enabling this mode by default should IMHO be avoided, since runaway
>> recursions (which is the usual reason for stack-exhaustion) will
>> consume all available memory and thus may bring the machine to a halt.
> 
> I think this is preferable to segfaulting and maps better to what the
> program is really doing; it *is* eating up all memory.  There are many
> reasons a program might segfault and they're always a bug.  Deep
> recursions are not by definition a bug and don't eat up all memory
> unless they're unbounded.

That these recursions are a bug is something I don't deny. The problem
is that we have to decide on a semantics that is practical to the
majority of use(r)s. So what should be done?

> 
> I think that seasoned Schemers tend to avoid non-tailrecursion as a
> matter of instinct, whereas beginners will use the recursive style more
> often so they will hit this bug more often (the original bug in Trac was
> also filed by someone who was doing SICP exercises).  Those are exactly
> the wrong people you'd want to have to explain to that they will need to
> rebuild their entire Scheme system to use their code as-is (yes, their
> entire system, since they're probably using the interpreter, as beginners).

That's right, of course. Build-options are also useless for those who
install binary packages and who don't want to mess with the build.
But a missing termination condition in a recursive function can happen
even to a seasoned Schemer.

On the other hand, there have been very few reports so far that the
current behaviour causes problems or appears inconsistent to users.
Preferably I'd like to do nothing, but provide an option for those
that think allowing heap-bounded deep recursions is important.

> 
> Furthermore, a program that does use a recursive process (whether written
> by a newbie or because it was simpler to express the algorithm that way)
> might seem to work fine for typical inputs, yet when larger inputs are
> fed to the program it would *suddenly* segfault.  If this option were
> enabled by default, it would degrade more gracefully, eating up more
> memory.  Hopefully this will be noticed before it eats all memory
> (if monitoring is in place, you will), but at least it won't result in
> an immediate denial of service.  At 4 in the morning.  So you get called
> out of bed to fix the damn server.

I'd prefer an immediate DoS instead of a server that just hangs,
swapping away like mad. 

> 
> I understand that there are differing viewpoints on this, but I think
> cutting it off at some arbitrary point when the stack is overflown is
> just as awkward as cutting off memory allocation at some arbitrary point.
> We let a user use up all available memory too by repeatedly consing onto
> a list.  I don't see why the C stack (an implementation detail which is
> irrelevant when coding in just Scheme) has to be treated differently.

I see your point. I just want to be pragmatic and I don't care too much
about the philosophical view on this - there are many machine limitations
that we have to deal with and this is just one of many. What do others
think about this?

There is always a performance impact. It is usually small, and depends
heavily on the code involved (It still gives me physical pain to know
that code is generated by the compiler that can easily be avoided, but
that's just me...)


cheers,
fleix