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

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 https://github.com/frehberg/rust/commit/337690e9b79ea9d8147d36f09dd8e949d72116f9

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

Start by reading the proposed process-handle design and the linked process_handle branch and commit. Compare the death-pipe approach with current std::process wait and SIGCHLD handling, then investigate portability requirements for Posix, Windows, and VxWorks. Done would require an agreed RFC design rather than a localized code change.