libstd: remove some mutable statics in sys::unix #74006
Merged
Conversation
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
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Could someone from @rust-lang/libs take a look at this? |
SimonSapin
approved these changes
Jul 5, 2020
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.
src/libstd/sys/unix/args.rs
Outdated
| .map(|i| { | ||
| let cstr = CStr::from_ptr(*ARGV.offset(i) as *const libc::c_char); | ||
| let cstr = CStr::from_ptr( | ||
| *ARGV.load(Ordering::Relaxed).offset(i) as *const libc::c_char |
There was a problem hiding this comment.
Would it make a difference to move this load out of the loop?
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.
euclio
force-pushed
the
sys-unix-static-mut
branch
from
b8b8a93 to
7d7f167
Compare
dtolnay
added
the
T-libs
|
Looks good, thanks! @bors r+ |
|
📌 Commit 7d7f167 has been approved by |
bors
added
S-waiting-on-bors
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.
bors
added
S-waiting-on-author
euclio
force-pushed
the
sys-unix-static-mut
branch
from
7d7f167 to
792f2de
Compare
|
Fixed, should be ready for another run. |
|
@bors r+ |
|
📌 Commit 792f2de has been approved by |
bors
added
S-waiting-on-bors
|
⌛ 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.
|
@bors retry yield |
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. |
|
☀️ Test successful - checks-actions, checks-azure |
|
This PR caused a regression: there are now aliasing violations in the argc/argv handling. |
|
Ah, this is probably caused by the integer-ptr-casts that |
|
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-actions bot
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-actions bot
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-actions bot
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
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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.