This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 29 Aug 2019 08:26:06 -0300
- Subject: Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls
- References: <20190731183136.21545-1-adhemerval.zanella@linaro.org> <20190731183136.21545-4-adhemerval.zanella@linaro.org> <875zmg9xjr.fsf@oldenburg2.str.redhat.com>
On 29/08/2019 05:38, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> * include/atomic.h (atomic_fetch_or_seq_cst, atomic_fetch_or_seq_cst):
>> New macros.
>
> Why isn't a regular release store/acquire load synchronization
> sufficient here?
It should works, my understanding is a weaker store barrier might incur in
a slight more false positive in a highly concurrent sigaction call scenario.
But I assume that this is not a common scenario, so I used the strongest
barrier just to avoid the extra false positives.
>
> I wonder if we can get kernel support for this in the new clone system
> call with more flags. Then we don't have to complicate the sigaction
> implementation.
Maybe a CLONE_RESET_SIGNALS where the cloned process sets its signal
disposition to default SIG_IGN/SIG_DFL values may help us here. However
afaik clone now is out of space on 'flags' for newer ones (it already
defines 24 flags plus it reserve 8 bits for signal to be sent at process
exit) and it would take time to use this feature on glibc.