Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)

[felix . winkelmann]

> On Sun, Nov 01, 2015 at 01:36:53AM +0100, address@hidden wrote:
> > Is this really necessary? I think runtime.c is already complicated enough 
> > as it
> > is. I understand your intent, but I'm always wary of "arbitrary fixes to 
> > reasonable
> > limitations, just because they are limitations". I think an arg-limit makes 
> > sense,
> > there are certain constructs that don't scale. If I have to pass 10 million 
> > arguments
> > to a procedure, I'm probably doing something wrong.
>
> I know what you mean, but we've seen that in practice there are some
> libraries that heavily rely on apply, most notably SSAX's sxml
> transformations.  And an XML element with 4096 child nodes isn't
> especially huge.

That doesn't change the fact that it is very bad programming style. It doesn't
scale, is not portable and very inefficient. Endorsing such a programming style
encourages writing bad code, therefore I really recommend a hard limit.

> One of the tricky parts about the temporary stack size is that it limits
> the parameter count, but *only* when the affected procedure is invoked
> precisely when the stack is full.  This could result in extremely tricky
> debug situations where a procedure works fine by itself, but in a program
> under *certain conditions* it would fail with an assertion error.  That's
> what happens now if you exceed the parameter limit in a direct
> invocation.  Of course this is even rarer than manyarg apply, but it
> could happen due to macro expansion.

I don't know, but this situation sounds a bit artificial to me, and such corner
cases are not limited to procedure calls. Or I don't understand the scenario
you describe. With "direct call" you mean a call without "apply", right?
Can you elaborate on those "certain conditions"?

>
> I don't think the change is that invasive; it only really affects one
> C function, and I've cleaned up some cruft that's no longer needed
> and simplified a test.

I understand, still every line added to runtime.c is a problem, IMHO.
But that is not the main motivation for my concern.

>
> Alternatively, we could just raise the limit of 4096 to something
> higher (what's an acceptable limit?), but that means pre-allocating
> more memory that's rarely actually used.  I think the less effectively
> "useless" memory we pre-allocate, the better.

I think 4096 is fine, as is anything larger. Memory consumption is not a
problem in the moment (a minimal program, or csi when started fresh, consumes 
relatively
little memory, at least the last time I checked)

Using apply with potentially unlimited argument lists (or even potentially very
large lists) looks sometimes like an easy way out, but is always wrong and 
should be
avoided (and can, in all cases I have encountered so far).


felix