Clarification of default socket flags by krhancoc · Pull Request #88805 · rust-l...
source link: https://github.com/rust-lang/rust/pull/88805
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New issue
Clarification of default socket flags #88805
Conversation
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.
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.
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
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.
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
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!
@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 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 (referencingCLOEXEC
on UNIX andHANDLE_FLAG_INHERIT
on Windows). Then, other places we open file-descriptors/handles could link to that explanation. (The existing mentions of this instd::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?
Copy link
rfcbot commented 18 hours ago
This is now entering its final comment period, as per the review above.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
No reviews
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK