Re: [PATCH 01/10] nptl: Perform signal initialization upon pthread_create

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 21/05/2021 06:58, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>>> Bu the main advantage is to move the cancellation code logically when
>>>> it is actually used, and it is small improvement on both static
>>>> linking (since the static code will be used solely is cancellation is
>>>> used) and on runtime (since sigaction will be set only if pthread_cancel
>>>> is called).
>>>
>>> Okay, I can prepare a version along these lines.  But in general, I
>>> consider less data and fewer conditionals an improvement.
>>
>> Thanks.
> 
> Unfortunately, it does not work with the present implementation.
> 
> sysdeps/unix/sysv/linux/createthread.c contains this:
> 
> 	      /* The operation failed.  We have to kill the thread.
> 		 We let the normal cancellation mechanism do the work.  */
> 
> 	      pid_t pid = __getpid ();
> 	      INTERNAL_SYSCALL_CALL (tgkill, pid, pd->tid, SIGCANCEL);
> 
> This obviously needs a working SIGCANCEL handler, so pthread_create and
> pthread_cancel are not as separate as we thought.

We can use __libc_signal_block_app on pthread_create instead of
__libc_signal_block_all and call __pthread_cancel on createthread.  The
SIGCANCEL is internal, so the race condition should not happen (assuming
well behave programs).  The pthread_cancel call on createthread can then
enable the signal.

> 
> So I think we should go with my original version for the time being.  We
> can switch to lazy initialization if we implement a different way for
> handling late thread creation failure.

Alright, I think we can change it later.

> 
> SIG_IGN handler disposition should not affect timer_create (which uses
> SIGCANCEL internally) because sigwaitinfo still wakes up on such
> signals.
> 
> Thanks,
> Florian
>