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

Florian Weimer fweimer@redhat.com
Tue May 12 19:17:07 GMT 2020


* 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).  */
>> +extern int __pthread_create_internal (pthread_t *newthread,
>> +				      const pthread_attr_t *attr,
>> +				      void *(*start_routine) (void *),
>> +				      void *arg, const sigset_t *new_sigmask);
>> +#if IS_IN (libpthread)
>> +hidden_proto (__pthread_create_internal)
>> +#endif
>
> OK.
>
>>  
>>  /* Functions with versioned interfaces.  */
>>  extern int __pthread_create_2_1 (pthread_t *newthread,
>> diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
>> index afd379e89a..2430d65723 100644
>> --- a/nptl/pthread_create.c
>> +++ b/nptl/pthread_create.c
>> @@ -603,10 +603,10 @@ report_thread_creation (struct pthread *pd)
>>    return false;
>>  }
>>  
>> -
>>  int
>> -__pthread_create_2_1 (pthread_t *newthread, const pthread_attr_t *attr,
>> -		      void *(*start_routine) (void *), void *arg)
>
> Could you please provide a detailed explanation of why we have a signal 
> mask here?

Why isn't the comment in the header file sufficient?

I find your requirement puzzling.

> Future reviewers of this code will be left wondering why the interface was
> designed as it is, and that's difficult to explain without a more thorough
> code audit.

Hmm.  NULL == use some default is pretty standard?  It's already used
for the attr argument.

>> @@ -873,6 +880,15 @@ __pthread_create_2_1 (pthread_t *newthread, const pthread_attr_t *attr,
>>  
>>    return retval;
>>  }
>> +hidden_def (__pthread_create_internal)
>> +
>> +int
>> +__pthread_create_2_1 (pthread_t *newthread, const pthread_attr_t *attr,
>> +		      void *(*start_routine) (void *), void *arg)
>> +{
>> +  return __pthread_create_internal (newthread, attr, start_routine, arg,
>> +				    false);
>
> My preference is to use NULL with an informative cast.
>
> Unless you can show existing practice. I'm not a fan of using false
> like this.

No, this is an accident.

Thanks,
Florian



More information about the Libc-alpha mailing list