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