Re: Fixed size of thread stacks in the nptl pthread implementation

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Feb 6, 2012 at 6:30 PM, Roland McGrath <roland@hack.frob.com> wrote:
> There are myriad ways to lose.
>
> In general, it's unpredictable whether the adjacent pages are available to
> expand a thread's stack. ?With address space randomization, it's literally
> random whether the space you want was occupied by something else. ?So if a
> particular program invocation requires a thread stack to grow, you're
> setting up a situation where it will work on some invocations and die on
> others, unpredictably. ?And that's just the most obvious example.

That is certainly a very serious issue and truthfully I'd forgotten
about address space randomization.

> I don't think the burden is on me to prove that it's a bad idea. ?If
> someone wants the feature, the burden is on them to make the case that it's
> actually really useful to have, and then to work through all the corner
> cases and unintended consequences and demonstrate that the whole situation
> is better than the status quo.

That makes a good for a good policy statement.

> This is an excellent example of something that might sound good at first
> blush to naive ears, but is fraught with peril that easily outweighs its
> supposed benefit.

Yes, so far they are:
* User applications have better local knowledge and should therefore
control their own stack growth.
* Address space randomization makes thread stack layout problematic
for future growth.
* Non-deterministic failure modes.

> I haven't even seen a statement of the problem someone thinks this change
> would be solving. ?The only obvious guess is that someone wants to make the
> default stack size small so the address space won't fill up when there is a
> large number of threads, yet wants to use large amounts of stack on some
> threads, yet doesn't want to understand their program well enough to simply
> explicitly set the appropriate stack size for each new thread. ?The
> split-stacks scheme addresses that scenario without introducing subtle
> weirdness and false-sense-of-security behavior to vanilla uses, and
> mitigates the danger of expecting more dynamically-grown stack than you can
> manage to get about as well as that danger can be mitigated for such a
> scenario.

Thank you for taking the time write out your previous single sentence
in long form.

I think that the consensus appears to be that dynamically growing
thread stacks if fraught with real problems.

Cheers,
Carlos.