Re: What can a thread do with PTHREAD_STACK_MIN?

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

On 12/21/2017 08:57 AM, DJ Delorie wrote:
> 
> "Carlos O'Donell" <carlos@redhat.com> writes:
>> I would like to get consensus on what a thread can do with
>> PTHREAD_STACK_MIN amount of stack.
> 
> As a programmer, if I read "this is the minimum stack size" I assume
> they included all their own overhead for normal "minimum user cases".
> 
> I.e. a thread that's created, does some processing that doesn't use
> stack, ends, and is joined.
> 
> The programmer can't predict what glibc will need for its own overhead,
> so specifying a minimum any less than needed for the above is pointless.
> 
> I don't know if this needs to include cancellation; I don't think I've
> ever cancelled a thread in my entire programming career so I wouldn't
> consider this "minimal".  However, I (as a programmer) also wouldn't
> expect a cancellation initiated by another thread to impact the stack
> usage of the cancelled thread, although in hindsight if signal handlers
> are involved...

Given that most applications do not use cancellation it would be a waste
of space to make PTHREAD_STACK_MIN require enough space for cancellation.
It would add quite a bit of extra stack space for this.
 
This does not include any accounting for the extra memory required by
any cancellation handlers that need to run.

Therefore I would propose an addendum about cancellation:
~~~
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. 

The value of PTHREAD_STACK_MIN does not include enough stack for the
thread in question to be cancelled. Cancellation requires an additional
unspecified amount of stack that depends on the cancellation handlers
to run and when the cancellation is acted upon.
~~~

That is the best I can say. We would need to tally how much memory the
unwinder takes and that might vary with the complexity of the start
routine and how many frames the unwinder needs to unwind.

-- 
Cheers,
Carlos.