This is the mail archive of the libc-alpha@sourceware.org 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]


* 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 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
build-many-glibcs.py tomorrow.

Thanks,
Florian


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