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

[Peter Bex]

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.

At the moment the limit isn't 10 million but more like 4096 :)

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.

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

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.

Cheers,
Peter

signature.asc
Description: Digital signature