pthread_cancel async-signal-safe
Florian Weimer
fw@deneb.enyo.de
Fri Dec 4 18:43:56 GMT 2020
* 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.
> 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.
More information about the Libc-alpha
mailing list