This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] nptl: Start new threads with all signals blocked [BZ #25098]

On 17/10/2019 18:49, Florian Weimer wrote:
> * Adhemerval Zanella:
>>> The cost of doing this is two rt_sigprocmask system calls on the old
>>> thread, and one rt_sigprocmask system call on the new thread.  (If
>>> there was a way to clone a new thread with a signals disabled, this
>>> could be brought down to one system call each.)  The thread descriptor
>>> increases in size, too, and sigset_t is fairly large.  This increase
>>> could be brought down by reusing space the in the descriptor which is
>>> not needed before running user code, or by switching to an internal
>>> sigset_t definition which only covers the signals supported by the
>>> kernel definition.  (Part of the thread descriptor size increase is
>>> already offset by reduced stack usage in the thread start wrapper
>>> routine after this commit.)
>> I think this change worth parametrizing it on Linux to save some space
>> on the pthread_t structure, since it save about 120 bytes per thread
>> and it is unlikely Linux will eventually increase the signal size.
> Do you see this as a precondition for this change?

I think we can add it as follow-up optimization, since it is orthogonal
to the change.

>> I think the idea of keeping the fields was that tools that abuse 
>> the ABI and access such metadata directly could work across glibc
>> versions. However, the C11 thread state already changed the internal
>> layout so I don't see much gain on keep this idea.  I would say to 
>> just remove the field altogether.
> I can certainly do that.
>>> +  /* Block alll signals, so that the new thread starts out with
>>> +     signals disabled.  This avoids race conditions in the thread
>>> +     startup.  */
>> s/alll/all
> Fixed locally.
>>> +  sigset_t original_sigmask;
>>> +  __libc_signal_block_all (&original_sigmask);
>>> +
>>> +  /* Conceptually, the new thread needs to inherit the signal mask of
>>> +     this thread.  Therefore, it needs to restore the saved signal
>>> +     mask of this thread, so save it in the startup information.  */
>>> +  pd->sigmask = original_sigmask;
>>> +#ifdef SIGCANCEL
>>> +  /* Reset the cancellation signal mask in case this thread is running
>>> +     cancellation.  */
>>> +  __sigdelset (&pd->sigmask, SIGCANCEL);
>>> +#endif
>>> +
>> Do we still have a nptl target that does not have SIGCANCEL support?
> I don't think so.  I can remove all the #ifdef's and run a build with
> tomorrow.
> Thanks,
> Florian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]