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 Tue, Jul 23, 2019 at 10:12:07AM +0200, Arnd Bergmann wrote:
> On Tue, Jul 23, 2019 at 2:01 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Rich Felker <dalias@libc.org> writes:
> > > On Sun, Jul 21, 2019 at 04:40:27PM -0500, Eric W. Biederman wrote:
> > >> Linus Torvalds <torvalds@linux-foundation.org> writes:
> > > I'm in agreement that if an extension to the waitid syscall is added,
> > > it should be P_PROCESS_PGID, not defining some special case for
> > > pid==0. It's not entirely clear but arguable that the standard
> > > requires EINVAL for P_PGID + pid==0, and plausible that there are
> > > applications that depend on this. We could emulate the EINVAL case in
> > > userspace, but assigning weird semantics to special cases is just a
> > > mess of potential future headaches when it would be trivial to do it
> > > right. And doing it right would also make programming userspace side
> > > easier.
> >
> > Since this is a POSIX interface and shared between many unices I took
> > at look at a couple to see what they have done.  If possible it is
> > important to be able to write programs that work the same across
> > different unices.
> >
> > The BSDs implemented wait6 as their common wait that does everything
> > system call.   It's large contribution is that wait6 will give both
> > the rusage of the child that exited and it's children separately.
> 
> Ah right, that was one more thing I forgot on my earlier list. If we end up
> creating a new wait4()/waitid() replacement  to replace the timeval
> with __kernel_timespec, we may want that to return a wrusage instead
> of rusage. Same for Christian's proposed pidfd_wait().

So I'm in the middle of writing tests for pidfd_wait. And I'm currently
using struct rusage. I would suggest sending out a first version using
struct rusage and then you can point out what you would like see as a
replacement. What do you think, Arnd?

Christian


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