Tracking Issue for process_set_process_group

[krallin]

Feature gate: #![feature(process_set_process_group)]

This is a tracking issue for: Add a process_group method to UNIX CommandExt

Add a process_group method to std::os::unix::process::CommandExt that
allows setting the process group id (i.e. calling setpgid) in the child, thus
enabling users to set process groups while leveraging the posix_spawn fast
path.

Public API

trait CommandExt {
    fn process_group(
        &mut self,
        pgroup: i32,
    ) -> &mut process::Command
}

Steps / History

• RFC: RFC: Add a process_group method to UNIX CommandExt rfcs#3228
• Implementation: Add a process_group method to UNIX CommandExt #93858
• Final comment period (FCP): Tracking Issue for process_set_process_group #93857 (comment)
• Stabilization PR: Document and stabilize process_set_process_group #99088

Unresolved Questions

• None yet.

[dtolnay]

This may or may not need a Fuchsia implementation. See #93858 (comment).

@rustbot ping fuchsia

[rustbot]

Hey friends of Fuchsia! This issue could use some guidance on how this should be
resolved/implemented on Fuchsia. Could one of you weigh in?

cc @tmandry

[niklasf]

Some updates:

• The final comment period of the RFC has concluded (RFC: Add a process_group method to UNIX CommandExt rfcs#3228 (comment)).
• The implementation has been completed and merged (Add a process_group method to UNIX CommandExt #93858).
• According to Fuchsia's target_family should be None, not "unix" #58590 (comment), Fuchsia has no process hierarchy. It seems sensible to do nothing for now (same as for CommandExt::groups). Eventually Fuchsia's target_family should be None, not "unix" #58590 will properly differentiate Unix and Fuchsia.

[joshtriplett]

T-libs-api, shall we stabilize process_group?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[BurntSushi]

This LGTM, but can we improve the docs for process_group please? I think it should at least mention:

• Why this routine might be useful. When does someone want to use process groups?
• Why it's superior to setting the process group via pre_exec. (I don't think we want to be overly specific here, but a hint saying something like, "this may allow the implementation to use a faster path" would be nice.)

[joshtriplett]

This LGTM, but can we improve the docs for process_group please? I think it should at least mention:

👍

* Why this routine might be useful. When does someone want to use process groups?

Some suggested documentation:

"Process groups determine which processes receive a signal when the user kills a process from its controlling terminal (e.g. hitting Ctrl-C to generate SIGTERM or Ctrl-\ to generate SIGQUIT). Shells and other programs that launch other programs use process groups to partition launched programs, such as foreground and background processes."

* Why it's superior to setting the process group via `pre_exec`. (I don't think we want to be overly specific here, but a hint saying something like, "this may allow the implementation to use a faster path" would be nice.)

As well as being safe, instead of the unsafe pre_exec.

[tmandry]

This may or may not need a Fuchsia implementation. See #93858 (comment).

Fuchsia does have a concept of jobs which have the same or similar role as process groups, but doesn't implement the POSIX notion of a process group id that's a universal integer. Instead, jobs (like all kernel objects) are represented by random 32-bit handles that are issued to a process by the kernel.

It might be possible to shoehorn this into the POSIX interface by passing a handle as a pid_t, but it's not clear whether this is a good idea (and anyway, we might remove some or all of std::os::unix for Fuchsia as @niklasf mentioned). Definitely don't block on us.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[JohnTitor]

Stabilized by #99088, closing.