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 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 my recommendation now is to avoid gratuitous incompatibilities.
>
> 1) For extending waitid.  Let's use P_PGID and and id of 0 to represent
>    the callers process group.  That is compatible with the BSDs, and
>    portable programs should not have any problem with it.
>
>    I want to stay away from the BSD extention of P_PID with an id of 0
>    meaning wait for the calling process's process group.  I see where
>    it comes from but that is confusing.
>
> 2) It appears the popular definition of current process group is the
>    current process group at the time of the system call.  Currently that
>    is Linux, FreeBSD, Illumos, and XNU.  So short of a real program that
>    cares, let's adopt that definition in linux.  Along with patches I
>    will see about getting the linux manpage updated to clarify that
>    point.

That all sounds reasonable to me, thanks for researching the other
implementations!

         Arnd


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