This is the mail archive of the
mailing list for the glibc project.
Re: Fixed size of thread stacks in the nptl pthread implementation
On Mon, Feb 6, 2012 at 6:30 PM, Roland McGrath <firstname.lastname@example.org> 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
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.