Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification of default socket flags #88805

Merged
merged 2 commits into from
Mar 4, 2022
Merged

Conversation

krhancoc
Copy link
Contributor

This PR outlines the decision to disable inheritance of socket objects when possible to child processes in the documentation.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @yaahc (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 10, 2021
@krhancoc
Copy link
Contributor Author

As an additional comment, I was unsure where this form of documentation belongs as its a design decision that is done throughout the Rust networking stack, but also is an implementation detail. I do think default options/flags should be explicitly stated somewhere though.

@JohnCSimon JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 28, 2021
@apiraino apiraino added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Oct 8, 2021
@yaahc yaahc added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 21, 2021
@yaahc
Copy link
Member

yaahc commented Oct 21, 2021

As an additional comment, I was unsure where this form of documentation belongs as its a design decision that is done throughout the Rust networking stack, but also is an implementation detail.

This seems like as good a place as any. The other option I can think of would be to copy-paste this same explanation into the docs of every function where this info applies.

I do think default options/flags should be explicitly stated somewhere though.

That's fair, though I want to note that we treat comments like these in our documentations as part of our stable API so this will require approval from the entire libs-api team. Also (mostly unrelated) thanks for the first contribution!

@rust-lang/libs-api do we want to document a commitment to disable socket inheritance where possible?

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Oct 21, 2021

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

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.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Oct 21, 2021
@joshtriplett
Copy link
Member

This is generally true for any kind of handle or file descriptor: we always set cloexec or equivalent. This doesn't seem like a change in our policy, just documentation of the existing policy.

@rfcbot reviewed

@yaahc yaahc added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 22, 2021
@krhancoc
Copy link
Contributor Author

This seems like as good a place as any. The other option I can think of would be to copy-paste this same explanation into the docs of every function where this info applies.

If this is the direction you folks would like to go I have no problem putting these default flags where applicable, the change would just effect far more files.

That's fair, though I want to note that we treat comments like these in our documentations as part of our stable API so this will require approval from the entire libs-api team. Also (mostly unrelated) thanks for the first contribution!

Thank you! Really enjoying rust so far and hope to contribute more substantially in the future!

@joshtriplett
Copy link
Member

@krhancoc I'd love to see a canonical explanation added to some module documentation (e.g. std::fs::File), explaining that we arrange for files to not be inherited by child processes by default (referencing CLOEXEC on UNIX and HANDLE_FLAG_INHERIT on Windows). Then, other places we open file-descriptors/handles could link to that explanation. (The existing mentions of this in std::process::Command can also link to the same explanation.)

@krhancoc
Copy link
Contributor Author

@krhancoc I'd love to see a canonical explanation added to some module documentation (e.g. std::fs::File), explaining that we arrange for files to not be inherited by child processes by default (referencing CLOEXEC on UNIX and HANDLE_FLAG_INHERIT on Windows). Then, other places we open file-descriptors/handles could link to that explanation. (The existing mentions of this in std::process::Command can also link to the same explanation.)

That sounds great. I can go craft that up -- would you folks rather it extend on top of this pull request or as a different one?

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Oct 27, 2021
@rfcbot
Copy link

rfcbot commented Oct 27, 2021

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

@joshtriplett
Copy link
Member

@krhancoc As a separate PR, please. And thank you for working on this!

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Nov 6, 2021
@rfcbot
Copy link

rfcbot commented Nov 6, 2021

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.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Nov 6, 2021
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Nov 11, 2021
@camelid camelid added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels Mar 3, 2022
@camelid
Copy link
Member

camelid commented Mar 3, 2022

triage: It looks like the FCP finished. @yaahc I believe this is waiting on your review.

Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@dtolnay
Copy link
Member

dtolnay commented Mar 3, 2022

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 3, 2022

📌 Commit a10f095 has been approved by dtolnay

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 3, 2022
@dtolnay dtolnay assigned dtolnay and unassigned yaahc Mar 3, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 4, 2022
Clarification of default socket flags

This PR outlines the decision to disable inheritance of socket objects when possible to child processes in the documentation.
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 4, 2022
Rollup of 10 pull requests

Successful merges:

 - rust-lang#88805 (Clarification of default socket flags)
 - rust-lang#93418 (rustdoc & doc: no `shortcut` for `rel="icon"`)
 - rust-lang#93913 (Remove the everybody loops pass)
 - rust-lang#93965 (Make regular stdio lock() return 'static handles)
 - rust-lang#94339 (ARM: Only allow using d16-d31 with asm! when supported by the target)
 - rust-lang#94404 (Make Ord and PartialOrd opt-out in `newtype_index`)
 - rust-lang#94466 (bootstrap: correct reading of flags for llvm)
 - rust-lang#94572 (Use `HandleOrNull` and `HandleOrInvalid` in the Windows FFI bindings.)
 - rust-lang#94575 (CTFE SwitchInt: update comment)
 - rust-lang#94582 (Fix a bug in `x.py fmt` that prevents some files being formatted.)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4c70200 into rust-lang:master Mar 4, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.