Re: What can a thread do with PTHREAD_STACK_MIN?

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

On 20/12/2017 18:56, Carlos O'Donell wrote:
> On 12/20/2017 10:18 AM, Adhemerval Zanella wrote:
>> On 20/12/2017 15:30, Carlos O'Donell wrote:
>>> 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.
> 
> Agreed, we can add clarifications to pthread_create, pthread_join,
> and pthread_cancel.
> 
> Does this mean you agree with (a) through (c)?
> 

At first I would expected PTHREAD_STACK_MIN to allow all default pthread
functions to work as expected without stack adjustment, including cancellation.
But I give you that some sycalls might consume a lot of stack (for instance
the fallback copy_file_range which might allocate up to 8k before acting
on cancellation) plus plt resolution and libgcc requirement (the later we
can't really control). 

Worse is this can vary a lot depending of the architecture and I would want 
to avoid vary PTHREAD_STACK_MIN more than we already for each architecture 
(in fact I would like to check if we can't unify them with a default maybe 
varying by 32 and 64 architectures).

So I agree with (a) through (c) since I think we can't reliable set a
minimum stack to cancellation work.