RFC: process-handle for future async child-processes-term-handling

[frehberg]

I would like to propose a new RFC: introducing a process-handle to deal with termination of child-processes, and introducing a strict ownership model for child-processes, without the need for process-wide management of the signal SIGCHLD and no need for a shared collection of the exit-status of child-processes.

Currently std::process is managing processes either in synchronous way using the wait-function-family, or asynchronously via signal-handlers (SIGCHLD).

The problem is that such signals may be delivered to any thread running within the parent-process. So, dealing with the termination of child-processes in async manner will require a shared collection containing the process-status of all child-processes.

I want to propose an alternative to signal-handling to deal with the termination of child-processes in async manner, and introducing strict ownership for child-processes.

The concept is based on so called death-pipes (aka forkfd concept):
An anonymous pipe is established between parent-process (RX end) and the child-process (TX end). Here the parent-process may use RX end to poll for read-events (file descriptor) in async manner, for example using a future.
Now, if the child-process terminates the TX end is being destroyed and the RX-end in the parent process will receive and EOF read-event.

The EOF-event will wake up the corresponding polling, async task in the parent-process, which will call the wait-function to read the exit-status of the child-process and releasing the child-process-zombie.

The following patch is a first sketch of the concept (under construction)
Branch https://github.com/frehberg/rust/tree/process_handle
Patch frehberg/rust@337690e

The process-handle feature shall be portable to Posix, Win and VxWorks, etal.
BSD-Unix provides a native functionality 'libc::pdfork(..)', establishing the TX-end in parent-process.
Windows provides a native process-handle HANDLE as well.

Such process-handle will allow to introduce strict ownership model for child-processes, without painfull, process-wide signal-handling.

Pros:

• permits strict ownership and async-handling of termination of child-processes
• no shared collection required to deal with SIGCHLD signal and exit-status of child-processes
• on Posix/VxWorks etal the process-handle will be a file-descriptor, and can be handled by async/await framework.
• on Windows the process-handle will be the HANDLE-object provided by function CreateProcessA(..).

Cons:

• on Posix/VxWorks etal each child-process will cause an additional file-descriptor in parent process and a non-referenced file-descriptor in child-process.
• legacy signal-handlers dealing with SIGCHLD might consume the exit-status before the owning async task got a chance to read the exit-status, therefore the SIGCHLD signal-handling should be disabled in the parent-process, or just be used for legacy code.

Comments are welcome

[frehberg]

Please comment PR RFC process-handle-for-async
#2823

[thiagomacieira]

Hello @frehberg

There's a difference between your description of forkfd and the implementation of forkfd in my code. You're describing the TX end of the pipe on the child process, but the implementation of forkfd keeps both ends of the pipe in the parent process. That means it adds to two file descriptors to the process's global count.

I highly discourage leaving the file descriptor in the child process. Doing so is extremely fragile. The child process might close it for other reasons, in which case the parent gets notified of "death" before the death has actually occurred. Worse, since the child does not know about this fd, it will likely leak it to grandchildren, which will cause the pipe to be kept open even after the direct child has died. It'll also accumulate, so 10 generations later you have 10 file descriptors open. A long-running process set that respawns itself, for example, could exhaust the fd table.

[frehberg]

HI @thiagomacieira,

you are right, indeed, in your code the parent-process keeps both ends of the death-pipe and the child-process is closing both ends of the death-pipe. This is not the way I would implement it, but it seems to work ;) Wondering how this can trigger an event on the reading side in parent-process if the client-process terminates (?) My strategy would have been to keep the TX-end in client with CLOEXEC-flag being set, so prevent inheriting to sub-sub-process.

[thiagomacieira]

That would require cooperation from the child process. If you can guarantee that, then there are possibilities.

You can't set the CLOEXEC flag from the parent because if you did, the child wouldn't have the file descriptor in the first place, as you will call execve.

[frehberg]

As for the question, how to deal with child-processes on older Linux/Posix-Systems (the non-pidfd compatibility case), the following code illustrates the way, the QProcess implementation is working in this legacy environment successfully.
https://gist.github.com/frehberg/58cac82a332febd6aff0e188c825b699

The code can be executed in two modes 1) Not-Qt-Mode, keeping the read-end inparent-process and write-end in child-process. 2) Qt-Mode, closing both ends in forked child-process and keeping both ends in parent-process.

Compile the code using "gcc -o a.out test_dath_pipe.c"

And execute as "./a.out not-qt-mode" or "./a.out qt-mode"

It shows, that in both modes the parent-process receives the termination signal as POLLIN-event.

The way QProcess has been implemented is favourable, indeed, as it does not leak file-descriptors to sub-sub-processes.

I hope, this short code snippet illustrates the mechanisms, implementing the death-pipe on top of basic POSIX API in case the underlying OS does not provide a suitable native functionality.