On Wed, Nov 28, 2018 at 1:41 AM, Florian Weimer [off-list ref] wrote:
* Christian Brauner:
quoted
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.