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

[Roland McGrath <roland at hack dot frob dot com>]

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.

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.

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.

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.