chicken-hackers
[Top][All Lists]
Advanced

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

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


From: Arthur Maciel
Subject: Re: [Chicken-hackers] [PATCH][5] Make temporary stack resizable (fixes #1098)
Date: Sun, 1 Nov 2015 09:35:14 -0200


Em 01/11/2015 07:44, "Peter Bex" <address@hidden> escreveu:
>
> 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.

+1 for the idea, the intended benefits and the patch itself.

IMHO to avoid spending weeks of our precious future debugging magic stuff happening under "certain conditions" (like Peter recently did for another reason) is a strong rationale to apply these change, especially considering it will simplify the core.

Kind regards,
Arthur


reply via email to

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