pthread_cancel async-signal-safe

[Adhemerval Zanella]

On 04/12/2020 15:43, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 04/12/2020 15:29, Florian Weimer wrote:
>>> * Adhemerval Zanella via Libc-alpha:
>>>
>>>> Florian, I recall that you had investigate some issue regarding C++
>>>> exceptions and signal handler that you presented on previous GNU 
>>>> Cauldron, so I wonder if you might have an idea how we can fix it.
>>>
>>> I didn't realize that pthread_cancel was required to be
>>> async-signal-safe.  We don't have an async-signal-safe dlopen and we
>>> can't block signals during dlopen because that breaks the web browser
>>> sandboxes.
>>>
>>> Are sure that pthread_cancel is on the list?  I don't see it in
>>> signal-safety(7).
>>>
>>
>> It is on the 2.9.5 Thread Cancellation at 'Async-Cancel Safety' entry
>> in POSIX manual [1]:
>>
>>   "The pthread_cancel(), pthread_setcancelstate(), and pthread_setcanceltype() 
>>    functions are defined to be async-cancel safe."
> 
> Oh, sneaky.
> 
> I think we would have to write our own unwinder to comply with that.

Can't we move pthread_cancel_init to __pthread_initialize_minimal_internal?

> 
>> Also, neither pthread_setcancelstate nor pthread_setcanceltype are 
>> async-signal-safe due __do_cancel usage (which calls _Unwind_ForcedUnwind
>> which in turn might call pthread_cancel_init).
> 
> I think that's actually not a problem because you can get there only
> if pthread_cancel has previously initialized cancellation.
> 

Indeed, do_cancel would be called only if pthread_cancel has the 
CANCELED_BITMASK previously.