[PATCH] nptl: Provide a way to block all signals for the timer helper thread

[Carlos O'Donell]

On 5/14/20 4:32 PM, Adhemerval Zanella wrote:
> 
> 
> On 14/05/2020 16:33, Carlos O'Donell wrote:
>> On 5/14/20 2:30 PM, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>> On 5/12/20 3:17 PM, Florian Weimer wrote:
>>>>> * Carlos O'Donell:
>>>>>
>>>>>>> +/* Exactly like pthread_create if NEW_SIGMASK == NULL.  Otherwise, do
>>>>>>> +   not use the current signal mask for the new thread, but set it to
>>>>>>> +   *NEW_SIGMASK instead (without unblocking internal signals).  */
>>>>
>>>>
>>>> Suggest:
>>>>
>>>> /* Exactly like pthread_create if NEW_SIGMASK is NULL.
>>>>    Create the new thread using the thread descriptor at NEWTHREAD,
>>>>    and the thread attributes from *ATTR, executing provided START_ROUTINE
>>>>    with a single void argument ARG.  The last argument is not present in
>>>>    the public API for pthread_create, but is part of the internal glibc API.
>>>>    The last argument is the signal mask to be restored in the new thread,
>>>>    and is normally NULL, in which case the parent's signal mask is restored
>>>>    as mandated by the standard's requirement for pthread_create.  In some cases
>>>>    though you may wish to keep certain signals blocked to avoid race cases,
>>>>    and today this includes the helper thread created by SIGEV_THREAD where all
>>>>    signals are blocked except SIGCANCEL.  Thus the new_sigmask argument is
>>>>    primarily intended for the creation of helper threads not user threads.  */
>>>
>>> Does this mean you think this interface is more generally useful?
>>
>> It might. I haven't reviewed C11 threads, getaddrinfo_a or aio uses.
> 
> If we eventually decouple SIGCANCEL and SIGTIMER this interface will most
> likely be removed as well.  Not sure if it would be better to add extra
> comments to document the behavior of if the VCS itself is a better tool.

I'm happy if we limit the scope.

Suggest:

/* This interface is *only* for use by pthread_create or SIGEV_THREAD
   helper threads.  We expect it will go away when SIGCANCEL and
   SIGTIMER are decoupled.  */

Then it's clear nobody should use it.

-- 
Cheers,
Carlos.