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: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable


On Thu, Jul 25, 2019 at 6:40 AM Rich Felker <dalias@libc.org> wrote:
> On Wed, Jul 24, 2019 at 05:04:53PM -0700, Alistair Francis wrote:
> > On Tue, Jul 23, 2019 at 1:45 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > Sounds good to me, the debate over what rusage to use should not hold
> > > up the review of the rest of that syscall.
> >
> > I'm unclear what the final decision is here. What is the solution are
> > we going to have wait4() or add P_PROCESS_PGID to waitid()?
> >
> > As well as that what is the solution to current implementations? If we
> > add wait4() then there isn't an issue (and I can drop this patch) but
> > if we add P_PROCESS_PGID then we will need a way to handle kernels
> > with waitid() but no P_PROCESS_PGID. Although my new plan is to only
> > use the waitid syscall if we don't have waitpid or wait4 so it seems
> > like this will only affect RV32 for the time being.
>
> I would really like some indication which solution will be taken,
> since it impacts choices that will need to be made in musl very soon.
> My favorite outcome would be bringing back wait4 for rv32 (and
> no-time32 archs in general) *and* adding P_PROCESS_PGID. In the short
> term, just using wait4 would be the simplest and cleanest for us (same
> as all other archs, no extra case to deal with), but in the long term
> there may be value in having rusage that can represent more than 68
> cpu-years spent by a process (seems plausible with large numbers of
> cores).

Based on the feedback from Linus and Eric, the most likely outcome
at the moment seems to be an extension of waitid() to allow
P_PGID with id=0 like BSD does, and not bring back wait4() or
add P_PROCESS_PGID.

So far, I don't think anyone has proposed an actual kernel patch.
I was hoping that Eric would do it, but I could also send it if he's
otherwise busy.

      Arnd


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