This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What can a thread do with PTHREAD_STACK_MIN?


On 12/20/2017 08:58 AM, 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.
> ~~~
>

v2 text:
- Add cancellation information.

v3 text:
- Add signal, tls, and lazy binding information.

v4 text:
- Expand the cancellation information section a bit more.
- Add section about measuring the stack usage.

~~~
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
in effect, the depth of the call stack, and the architectural overhead
of the cancellation infrastructure for a given machine.

The value of PTHREAD_STACK_MIN does not include enough stack for running
signal handlers, either specifically setup for the thread, or those which
are randomly delivered to a single thread in the process by the OS kernel.

The value of PTHREAD_STACK_MIN does not include enough stack for all
of the static TLS data required by the thread. Currently the implementation
uses the thread stack to store static TLS data. This requirement will be
changing in the future, and static TLS data will not be counted as part of
the stack. This makes it easier for the user to compute the maximum stack
size needed.

Lastly, the value of PTHREAD_STACK_MIN does not include enough stack for
lazy binding requirements. If you application uses lazy binding and the
thread start routine calls functions which are lazily bound, those functions
must be immediate resolved by the dynamic loader. The dynamic loader itself
will consume some amount of stack to carry out the resolution.

For all unspecified stack amounts the user is responsible for measuring the
stack usage with developer tooling, and using that as a starting point.
~~~

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]