Uh oh!
There was an error while loading. Please reload this page.
libstd: remove some mutable statics in sys::unix - #74006
Merged
Merged
Conversation
rust-highfive
commented
Jul 3, 2020
Contributor
(rust_highfive has picked a reviewer for you, use r? to override) |
joshtriplett
commented
Jul 4, 2020
Member
Could someone from @rust-lang/libs take a look at this? |
SimonSapin
approved these changes
Jul 5, 2020
SimonSapin
left a comment
Contributor
There was a problem hiding this comment.
Per https://blog.rust-lang.org/inside-rust/2020/07/02/Ownership-Std-Implementation.html I think @rust-lang/compiler could also handle this. Anyway, this looks good.
Contributor
There was a problem hiding this comment.
Would it make a difference to move this load out of the loop?
Contributor
There was a problem hiding this comment.
Unlikely to make a perf difference, but I like it anyway, because it'll make it clear that there is no expectation of this loop to ever load a different value while looping.
SimonSapin
commented
Jul 6, 2020
Contributor
Looks good, thanks! @bors r+ |
bors
commented
Jul 6, 2020
Collaborator
📌 Commit 7d7f167 has been approved by |
Manishearth added a commit
to Manishearth/rust
that referenced
this pull request
Jul 6, 2020
…Sapin libstd: remove some mutable statics in sys::unix My understanding is that this achieves the same behavior and performance with safe code.
Manishearth
commented
Jul 6, 2020
Member
euclio
commented
Jul 7, 2020
ContributorAuthor
Fixed, should be ready for another run. |
oli-obk
commented
Jul 7, 2020
Contributor
@bors r+ |
bors
commented
Jul 7, 2020
Collaborator
📌 Commit 792f2de has been approved by |
bors
commented
Jul 7, 2020
Collaborator
⌛ Testing commit 792f2de with merge 42108486723e0a2d7d03888673ca838dd2d19cde... |
Manishearth added a commit
to Manishearth/rust
that referenced
this pull request
Jul 7, 2020
libstd: remove some mutable statics in sys::unix My understanding is that this achieves the same behavior and performance with safe code.
Manishearth
commented
Jul 7, 2020
Member
@bors retry yield |
bors
commented
Jul 7, 2020
Collaborator
Member
Relaxed accesses are slightly stronger than non-atomic accesses that were used before, and optimized a bit less. (IOW, behavior is slightly different.) So in theory this could lead to slightly worse performance. That seems unlikely in practice though, unless these are used in tight loops. |
bors
commented
Jul 7, 2020
Collaborator
☀️ Test successful - checks-actions, checks-azure |
RalfJung
commented
Jul 8, 2020
Member
This PR caused a regression: there are now aliasing violations in the argc/argv handling. |
RalfJung
commented
Jul 8, 2020
Member
Ah, this is probably caused by the integer-ptr-casts that |
RalfJung
commented
Jul 8, 2020
Member
I'll have to fix this by changes on the Miri side until we can handle int-ptr-casts better. |
bors added a commit
to rust-lang/miri
that referenced
this pull request
Jul 8, 2020
we cannot track all machine memory any more due to int-ptr-casts Fixes a regression introduced by rust-lang/rust#74006
bors added a commit
to rust-lang/miri
that referenced
this pull request
Jul 8, 2020
we cannot track all machine memory any more due to int-ptr-casts Fixes a regression introduced by rust-lang/rust#74006
ChrisDenton added a commit
to ChrisDenton/rust
that referenced
this pull request
Apr 21, 2025
Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang#74006 (cc `@euclio)` for Unix and rust-lang#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
rust-timer added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 21, 2025
Rollup merge of rust-lang#139711 - thaliaarchi:hermit-args, r=jhpratt Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang#74006 (cc `@euclio)` for Unix and rust-lang#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
github-actionsBot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Apr 22, 2025
Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang/rust#74006 (cc `@euclio)` for Unix and rust-lang/rust#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
github-actionsBot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Apr 23, 2025
Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang#74006 (cc `@euclio)` for Unix and rust-lang#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
github-actionsBot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Apr 24, 2025
Hermit: Unify `std::env::args` with Unix The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix. The atomic orderings were established in rust-lang/rust#74006 (cc `@euclio)` for Unix and rust-lang/rust#100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match. Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit. cc `@mkroening` `@stlankes` for Hermit
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My understanding is that this achieves the same behavior and performance with safe code.