Andy Wingo <wi...@pobox.com> writes:
> Hey Guilers,
Hi Andy,
In summary, I'm not sure I'm following the logic here...
> The recent commit to compile with the stack calibration file,
> 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the
> compile scripts have hash-bang lines like this:
>
> #!/bin/sh
> # -*- scheme -*-
> exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 "$@"
> !#
FWIW, I think this kind of incantation is really horrible. Ditto for
usage of "guile-tools ...". What kind of a scripting language is it
that needs to be bootstrapped by a different language?
Anyway, I see the breakage... (Probably almost any change would break
something so fragile.)
> Also, it is a bit irritating to have to load a file just so Guile won't
> be broken (exaggerated wording, but I think that's what it is.)
I think you may be misunderstanding. stack-limit-calibration.scm
should make precisely 0 difference on the "canonical build platform" -
which in practice means ia32 GNU/Linux.
As Guile stands (and notwithstanding your idea that we could use
getrlimit instead), we do hardcode _some_ stack depth limit. Once
that was 20k, then 40k, and you're now suggesting 60k. Those are
supposed to be values that will work on the canonical platform.
stack-limit-calibration.scm is all about scaling down/up the hardcoded
value for a non-canonical platform that might use more or less stack
on average than the canonical platform - e.g. because it has fewer
registers, because its pointers are twice the size (ia64) etc.
The primary purpose of stack-limit-calibration.scm is to allow "make
check" to succeed on those platforms, and it now makes sense to
generalize that to any other guile-using operations that we run during
the build - such as compiling.
It would probably also make sense to install
stack-limit-calibration.scm, so that 3rd party programs could also use
it; but we don't currently do that.
> So I have a proposal. We should set the stack limit to 60k words.
If we need 60k on the canonical build platform, we should have 60k.
No issue there.
> Pros: 1) This way Guile will just work.
(For you. Other platforms may still need stack-limit-calibration.scm.)
> 2) It's simple.
> 3) We avoid the evaluator this way.
>
> Cons: 1) A stack-consuming process will take longer to catch.
Not a problem. Any individual program can set the stack limit
differently, if they so choose.
> I cannot think of any other cons. GC just marks between the stack base
> and the stack pointer anyway. This would be 500 kB on x86-64, but a
> normal program would never use that, and last time I looked processes
> had 2 MB of stack by default anyway. It would be 250 kB on Linux.
>
> If we were really concerned about processes actually consuming all of
> their stack, we should use a value from getrlimit(2) instead.
I don't think that is the concern. I think the idea is to catch
incorrectly written (i.e. usually non-tail-recursive) programs before
they crash.
Regards,
Neil
