process: add dup2 file action

[avikivity]

Support the posix_spawn_file_actions_adddup2() library call.

The direct motivation for this is the jobserver crate using pre_exec to clear the CLOEXEC flag on the jobserver fd. This disables the vfork optimization and slows down posix_spawn() greatly.

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 68 candidates
• Random selection from 14 candidates

[avikivity]

Disclosure: I was assisted by AI to prepare the patch. I believe it is of good quality.

[petrochenkov]

r? library

[rustbot]

Failed to set assignee to library: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[petrochenkov]

r? libs

[joboet]

Disclosure: I was assisted by AI to prepare the patch. I believe it is of good quality.

Thank you for the honesty!

Was this discussed previously by T-libs-api? In any case, I have some questions about the API:

• I'm not a big fan of the name dup2_file_action – how about something like set_fd?
• Changing the file descriptor table of the spawned process isn't relevant for I/O safety in the current process. So if you accept BorrowedFd or (even better) impl AsFd as a first argument, the function could be made safe (although it's probably advisable to check for conflicts between actions).
• It may be nice to extract the "clear-CLOEXEC" case to a separate function like inherit_fd or something like that (that definitely could be made safe).

And also,
r? libs-api

[bjorn3]

How is this different from #145687?

[avikivity]

How is this different from #145687?

At least:

• this one is documented, the other has to be reverse-engineered to understand what it does
• this one is being maintained, the other appears abandoned

It's possible that the contents are equivalent.

[avikivity]

Disclosure: I was assisted by AI to prepare the patch. I believe it is of good quality.

Thank you for the honesty!

Was this discussed previously by T-libs-api?

I don't know. I don't even know what a T-libs-api is. I'm not a regular Rust contributor.

In any case, I have some questions about the API:

• I'm not a big fan of the name dup2_file_action – how about something like set_fd?

I think dup2_file_action, while clumsy, is better. We're not implementing some general computing concept, we're plumbing an existing API. It's likely users will approach it from the point of "how do I push a dup2_file_action through the process API (coming from below, the Linux direction) rather than "let's explore the process API and see what tools it gives me" (coming from above, the application direction). It solves a very low-level problem.

That said, I'll happily adjust to conform to the library's wishes.

• Changing the file descriptor table of the spawned process isn't relevant for I/O safety in the current process. So if you accept BorrowedFd or (even better) impl AsFd as a first argument, the function could be made safe (although it's probably advisable to check for conflicts between actions).

Understood, I'll try it.

• It may be nice to extract the "clear-CLOEXEC" case to a separate function like inherit_fd or something like that (that definitely could be made safe).

Ok.

And also, r? libs-api

Awaiting your preference on the naming.

[bjorn3]

I think dup2_file_action, while clumsy, is better. We're not implementing some general computing concept, we're plumbing an existing API.

It wouldn't use posix_spawn_file_actions_adddup2 if fork+exec (or just exec if the user wanted to replace the current process). posix_spawn_file_actions_adddup2 is an implementation detail of the actual operation that this does: Passing an fd to the new process.

[bjorn3]

Can this accept an OwnedFd or BorrowedFd as input fd to make this function safe?