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 04:53 AM, Adhemerval Zanella wrote:
> 
> 
> 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.

It is the same problem in C++.

How much *additional* stack do you need in order to throw at any point in
the call stack? Nobody tells you this number. You measure it empirically
and add some for safety and hope it works.

Though in C people think it should be easier to compute this bound, but
it's just as hard, we use the same C++ unwinding mechanisms.

I've had at least two users I've polled say they would expect cancellation
to work under PTHREAD_STACK_MIN. That is a really hard problem to solve
though, and therefore I think we can't guarantee it and should explicitly
say so.

-- 
Cheers,
Carlos.


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