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

[Ian Lance Taylor <iant at google dot com>]

"Carlos O'Donell" <carlos@systemhalted.org> writes:

> Is there any reason, when looking at split-stack, that it was not an
> intermediate option to reduce default thread sizes and grow the thread
> stacks dynamically (in the traditional manner)? While such a solution
> is not as good as split-stack, it would have been a short-term
> solution to reduce thread stack size to the approximately required
> size (as opposed to the large static stack sizes used by glibc today).

Growing the thread stack dynamically without splitting it assumes that
you have reserved the address space ahead of time.  If you haven't
reserved it, then you will fail at runtime when a thread needs a bigger
stack.  And I don't see a real difference in practice between reserving
the address space for a large stack and simply allocating a large stack.
It's not a solution for the problem that split stacks solve, which is
the ability to have large numbers of execution threads without burning
lots of address space on stacks and without worrying that one of the
threads might need to do a deep series of function calls.

Ian