This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: extending wait4(2) or waitid(2) linux syscall
On Wed, Nov 28, 2018 at 1:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
> * Christian Brauner:
>
>> The intention has always been to start a
>> file descriptor process API off of that.
>> If we land my procfd_signal() patchset we are in good shape for
>> procfd_wait(), imho.
>
> How does this interact with SIGCHLD and the wait system call (or any
> wait function without an explicitly specified PID)?
It doesn't, but let's take one step at a time. procfd_signal() is a
good first step. Once procfd_signal() and procfd_wait() exist, and
managing processes with FDs in general no longer seems odd, we can add
a clone() option that 1) avoid wiring a new subprocess up to the
legacy PID-based process-management API, and 2) returns one of these
fancy new FDs that works with procfd_signal and procfd_wait. (How we
do that without /proc mounted is an open question, but solvable in a
few options.)
> I understand that I have somewhat conflicting requirements, but in terms
> of relative priorities, launching a process without spurious signals and
> wait notifications would probably offer the larger benefit.
I also want a non-process-wide subprocess API. A clean FD-based API is
how you get it--- it's not an either-or situation. Considering that we
want to use FDs for general-purpose process management in the future,
it'd be not only a waste of time, but actually counterproductive, to
design a non-FD-based API for this non-process-wide sub-process use
case.