libstd: remove some mutable statics in sys::unix #74006
Conversation
|
(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? |
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
…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... |
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. |
we cannot track all machine memory any more due to int-ptr-casts Fixes a regression introduced by rust-lang/rust#74006
we cannot track all machine memory any more due to int-ptr-casts Fixes a regression introduced by rust-lang/rust#74006
My understanding is that this achieves the same behavior and performance with safe code.