This is the mail archive of the
mailing list for the glibc project.
Re: What can a thread do with PTHREAD_STACK_MIN?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Wed, 20 Dec 2017 18:19:05 +0100
- Subject: Re: What can a thread do with PTHREAD_STACK_MIN?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
On 12/20/2017 05:58 PM, Carlos O'Donell wrote:
I see that both of you have been looking at pthread issues involving
stack, guards, and TLS, and their relative relations to stack sizes
in the APIs.
I would like to get consensus on what a thread can do with PTHREAD_STACK_MIN
amount of stack.
I propose the following:
The implementation only guarantees that a thread with PTHREAD_STACK_MIN
can be created, but such space does not take into consideration the
thread's stack requirements to execute the start routine. No additional
space, beyond that for the start routine, should be required to join the
Therefore for a thread to be both startable and joinable it must have
PTHREAD_STACK_MIN stack and the stack required for start routine as a
Does this mean new targets should define PTHREAD_STACK_MIN as zero, if
we continue to exclude the guard and TLS sizes from the stack size?
This is not at all how PTHREAD_STACK_MIN is used by GNU/Linux
applications, though, which is why I don't think this interpretation is
I don't think we can realistically provide a complete fix for this any
time soon (which involve documenting glibc function stack size
requirements, so that applications can review their stack size choices).
So I think the only way forward is to address regressions as they
arise, by reducing the size of stack frames or change the way the stack
size is accounted.