Add pidfd-based implementation of `tokio::process`

[Aaron1011]

Is your feature request related to a problem? Please describe.
The current unix implementation of tokio::process relies on handling SIGCHLD signals. This requires that the corresponding signal handler be properly set up - if another library in the process modifies it, it will be impossible to properly wait on child processes.

Describe the solution you'd like
On recent versions of Linux, it's possible to use pidfds to avoid this problem. Using the recently merged libstd support (rust-lang/rust#81825), we can create a pidfd at the same time that a child is spawned. The pidfd can then be waited on using epoll or select (with an optional timeout).

If the running kernel version does not support pidfds, we can fall back to the existing unix implementation.

Describe alternatives you've considered
Do nothing, and continue to use the unix implementation in all cases.

[Darksonn]

@ipetkov

[ipetkov]

Worth noting that we may need to wait for our MSRV includes this change before we can roll it out as a feature

[Aaron1011]

I think this could be gated behind some kind of nightly feature to allow users to get early access to it.

[mmstick]

The feature has already been around in a crate, so there's no need for wait for a Rust compiler update. Trivial to implement by scratch as well.

[Aaron1011]

Getting the full benefits of this feature (eliminating the issue of pidfd wraparound, and removing the dependency on signal handlers) requires going through the standard library, so that we can obtain a pidfd at the same time the child process is spawned.

[MikailBag]

It is safe to obtain a pidfd using the pidfd_open syscall right after child creation. PID can only be recycled after the child has been wait-ed for. AFAIK the only downside is kernel support: clone has CLONE_PIDFD flag since 5.2, and pidfd_open is only available in 5.3

[Aaron1011]

PID can only be recycled after the child has been wait-ed for.

Yes, but calling wait(-1) will wait on the children of all threads, not just the current thread. If a Rust program includes a C library that calls wait (or if the Rust program is used as a library in a larger C program), then PID recycling is no longer under the control of the Rust code.

I recognize that this is an edge case - however, recent versions of Linux now have all of the tools needed to wait for child processes in a truly 'self-contained' manner, which does not need to make any assumptions about other code running in the same process. I think it would be great to be able to take advantage of that in Tokio, when the kernel version in use supports it.

[mmstick]

Getting the full benefits of this feature (eliminating the issue of pidfd wraparound, and removing the dependency on signal handlers) requires going through the standard library, so that we can obtain a pidfd at the same time the child process is spawned.

There's nothing that they can do that isn't already being done in the two pidfd crates. You obtain a pidfd after a process has been spawned, the kernel guarantees that the child's PID will remain valid until three child is reaped by waiting on the process.

I use this crate in a lot of my projects and have never had to use signal handlers.

[Darksonn]

Which Rust version was this released in?

[Aaron1011]

There's nothing that they can do that isn't already being done in the two pidfd crates. You obtain a pidfd after a process has been spawned, the kernel guarantees that the child's PID will remain valid until three child is reaped by waiting on the process.

The reaping can happen by some other code outside of the user's control (e.g. a background thread). Creating the pidfd along with the process is the only approach that is guaranteed to be free from race conditions in the face of additional calls to waitpid() outside of the Rust code's control.