Re: What can a thread do with PTHREAD_STACK_MIN?

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 20/12/2017 15:30, Carlos O'Donell wrote:
> 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.
> 

I think we also need document that thread cancellation requires some 
stack usage from libgcc for the stack unwinding, since it might not be
obvious getting a stack overflow with pthread_cancel.