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/21/2017 12:10 PM, Florian Weimer wrote:
> On 12/21/2017 06:09 PM, Carlos O'Donell wrote:
>> 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.
>> ~~~
> 
> I think this should mention signal handlers (including signals which
> are send to the process and may randomly end up on this thread), lazy
> binding, and, at least for now, static TLS.

Is there any possible way to limit how much stack the lazy binding would
consume? You have to find the symbol and resolve it, which could mean
doing a lot of work in the dynamic loader.

What should it say?
~~~
...

The value of PTHREAD_STACK_MIN does not include enough stack for running
signal handlers, either specifically setup for the thread, or 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. The amount
of stack required to do so is unspecified and must be measured by the
application author in order to compute the needed size.
~~~

Like so?

> I'm also not sure where we would put this information, due to the
> general lack of pthread documentation.

Solvable. We just start a pthreads section. Agreeing on the content
is what's hard :-)


-- 
Cheers,
Carlos.


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