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 4/5] linux: Optimize posix_spawn spurious sigaction calls

* 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

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

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


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