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

On Mon, Oct 07, 2019 at 08:32:52PM +0200, Florian Weimer wrote:
> * Christian Brauner:
> >> >>>>> 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.
> >> >>>>
> >> >>>> Christian Brauner has been working on fixing this.
> >> >>>
> >> >>> Which strategy he is proposing? Even with proper kernel support, it would
> >> >>> take time to enable glibc to use it.
> >> >>
> >> >> Lots of flag arguments, with the reset of the arguments located
> >> >> indirectly via a pointer argument.
> >> >>
> >> >> For a pure optimization, I think it's not too bad to require kernel
> >> >> backports of system calls.
> >
> > So I just accidently caught wind of this discussion. :)
> Good. 8-)
> > I'm open to extending clone3() to support something like the above.
> > My new clone3() version has been released with Linux 5.3. It takes a
> > struct clone_args. The structure is versioned by size and thus - in
> > theory - extensible indefinitely.
> Christian, would you be able to implement the CLONE_RESET_SIGNALS flag
> for us?  It should reset any handler which is not SIG_IGN or SIG_DFL to
> SIG_DFL.  We'd also need a way to probe that the flag is supported, so
> that we can fall back to the current way of doing things otherwise.

Yeah, I can implement this. It shouldn't be too much work and if I can
Cc you and point out that you'd need/want this feature I can send a PR
for my thread updates for the 5.5 merge window.
Would that work for you?


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