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: extending wait4(2) or waitid(2) linux syscall

On Wed, Nov 28, 2018 at 1:41 AM, Florian Weimer <> 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

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