Re: [PATCH 12/23] nptl: Introduce __nptl_deferred_init

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 14/05/2021 23:02, Carlos O'Donell wrote:
> On 5/14/21 3:27 PM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>>> We don't really need in fact, pthread_cancel can call __pthread_exit
>>>> directly if the argument is THREAD_SELF. And with my canceltype and
>>>> cancelstate refactor we don't even need the whole atomic bit set
>>>> support.
>>>
>>> And POSIX in the RATIONALE says exactly this:
>>> ~~~
>>> The special function also means that implementations are not obliged
>>> to implement cancellation with signals.
>>> ~~~
>>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cancel.html
>>
>> My question was whether we use the signal mask to block cancellation,
>> but I don't think that's the case (except in some cases where we block
>> *all* signals for other reasons).
>>
>> But calling pthread_exit is probably not the right thing to do because
>> pthread_cancel is itself not a cancellation point.
>>
>> In any case, I really don't want to change the implementation as part of
>> this series.
> 
> I agree that not changing things during a refactor is an important
> part of avoiding regression.
> 
> Adhemerval, Do we agree that this can be changed later?
> 

Fair enough, I have some patches I am working to try simplify the
cancellation handling (and hopefully get the long-standing BZ#12683
fix).