This is the mail archive of the
mailing list for the glibc project.
Re: What can a thread do with PTHREAD_STACK_MIN?
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.