This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/7] Block all signals on timer_create thread (BZ#10815)
On 12/12/2019 12:14, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>>> I think this does not unblock SIGCANCEL on the new thread with the
>>> current pthread_create implementation. This will change with the
>>> block-signals-around-clone patch I submitted, though.
>>
>> It does not indeed, although not sure how valid is the scenario to
>> pthread cancel a thread not created explicitly by a pthread_create
>> issued by the user (since POSIX also state it is not valid to call
>> pthread_join() timer thread).
>
> I don't see any restrictions on calling pthread_cancel or pthread_exit.
>
>> The sigcancel is explicit blocked with __libc_signal_block_sigtimer
>> on __start_helper_thread, so sigwaitinfo would be the only point
>> where the timer is triggered. I don't think it is correct to unblock
>> it before calling pthread_create, so the created thread inherit the
>> unblock SIGCANCEL, for the same reason the SIGCANCEL is blocked on the
>> helper thread that calls sigwaitinfo (possible lose wakeups).
>
> We can wrap the thread start function with another function that
> unblocks SIGCANCEL. Or note the semantic difference on the other change
> (which I assume we still want for other reasons).
We can add such call ontimer_sigev_thread, but it does not really
help the 'rt' side of the function with another syscall. Do you
consider this a block? Should we reinstate the sigprocmask to
unblock SIGCANCEL on timer_sigev_thread?