Re: What can a thread do with PTHREAD_STACK_MIN?

[Carlos O'Donell <carlos at redhat dot com>]

On 12/20/2017 09:19 AM, Florian Weimer wrote:
> 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?

I don't think so, because we need to do a number of things in the
thread itself before calling the start routine, and PTHREAD_STACK_MIN
should be enough to run that code.

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

It is absolutely imperative that we continue to refine the semantics
of operations in order to provide our users with the best possible
experience.

In the past users used PTHREAD_STACK_MIN and *hoped* they could do
a few things without having problems.

I'm saying we should clarify this to mean exactly as I say above.

> 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.
That is a solution that targets QoI, and it also has value.

I don't think that we can or should document glibc function stack sizes.

I think users need to use runtime stack watermarking and measurement to
determine their operational requirements, and then use pthread_attr_setstacksize
to set the right size (without being robbed by guard and TLS pages).

So my position stands:

(a) Make it very clear that PTHREAD_STACK_MIN is the minimum required to
    start the thread, from now, going forwards.

(b) Do our best to honour the relaxed semantics that allowed users to run
    a few key functions in the past, this involves only getting back the
    extra stack we lost to xsave.

(c) Work to make it possible to use stack instrumentation and pthread_attr_setstacksize
    to accurately reflect what the application is doing.

-- 
Cheers,
Carlos.