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
On Wed, Oct 09, 2019 at 11:37:30AM +0200, Florian Weimer wrote:
> * Adhemerval Zanella:
>
> > On 07/10/2019 15:40, Florian Weimer wrote:
> >> * Adhemerval Zanella:
> >>
> >>> However, glibc supports older kernels as old as v3.2 and it will take
> >>> some years and releases to make v5.3 or new the minimum support kernel.
> >>> And I think it would be nice to have this optimization even for older
> >>> kernels.
> >>
> >> But wouldn't it make sense to backport clone3 to these older kernels, so
> >> that further enhancements are possible, in cooperation with the kernel.
> >
> > For a kernel standpoint sure, for libc one it only make sense if it becomes
> > de-facto kernel ABI. It can be quite feasible from a distribution standpoint,
> > where it controls both kernel and userland deployment. But it is not the only
> > scenario glibc aims to work neither we should prioritize it.
>
> Sure. But I think we should keep in mind here that this is not a
> localized optimization. It optimizes posix_spawn with something that
> extends into something that is (at least superficially) completely
> unrelated.
>
> If we can get kernel assistance for the optimization (and it looks like
> we'll receive it), we can avoid that complexity. The patch Christian
> posted is very small. It's on top of clone3, sure, but I expect that
> people will want the system call anyway for some container support case
> soon enough, so long-term maintained kernels will get it essentially for
> free.
Yeah, the time namespace patchset will introduce CLONE_NEWTIME and that
flag will only be possible with clone3() for obvious reasons. And I'm
pretty sure that a lot of database workloads will want that...
>
> Using the new clone3 flag looks inherently backportable to me on the
> glibc side. Compared to that, the sigaction changes look a bit risky to
> me.
In the future I would like certain sets of changes that we currently do
in a racy way in the child to be made right at process creation time.
Another flag that I has been in my mind for a long time is e.g.
pdeath_signal. There should probably be an extension to struct
clone_args that introduces a new member pdeath_signal which won't be
reset and will be delivered to the child once the parent dies.
Christian