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