Re: What can a thread do with PTHREAD_STACK_MIN?

[Florian Weimer <fweimer at redhat dot com>]

On 12/20/2017 05:58 PM, Carlos O'Donell wrote:
> Szabolcs, Florian,
>
> 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
> thread again.
>
> 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
> minimum.
> ~~~

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 
particularly useful.

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.

Thanks,
Florian