This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixed size of thread stacks in the nptl pthread implementation
On Tue, Feb 7, 2012 at 12:25 AM, Ian Lance Taylor <iant@google.com> wrote:
> "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.
Thanks, that make perfect sense.
Cheers,
Carlos.