-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rename compiler_barrier to compiler_fence #41262
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @parched |
f3edc1f
to
f9f3e16
Compare
This addresses concerns raised following the merge of rust-lang#41092. Specifically: > The naming of these seems surprising: the multithreaded functions (and > both the single and multithreaded intrinsics themselves) are fences, > but this is a barrier. It's not incorrect, but the latter is both > inconsistent with the existing functions and slightly confusing with > another type in std (e.g., `Barrier`). `compiler_fence` carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in `std`.
f9f3e16
to
368d560
Compare
I personally don't mind going either way on this, @jonhoo do you know if there's precedent for naming here we can draw from other languages perhaps? |
I've been struggling to find other languages that expose this feature beyond C++ (which exposes it as I was and am hesitant to go with the C++ name for two reasons: it is not exclusively for signals (interrupts are also an important use-case), and |
Thanks for researching precedence! I concur with the arguments for |
@bstrie I see what you're trying to do with |
I think |
@parched I'm actually skeptical of |
📌 Commit 368d560 has been approved by |
…lexcrichton Rename compiler_barrier to compiler_fence This addresses concerns raised following the merge of rust-lang#41092. Specifically: > The naming of these seems surprising: the multithreaded functions (and both the single and multithreaded intrinsics themselves) are fences, but this is a barrier. It's not incorrect, but the latter is both inconsistent with the existing functions and slightly confusing with another type in std (e.g., `Barrier`). `compiler_fence` carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use in `std`.
This addresses concerns raised following the merge of #41092. Specifically:
compiler_fence
carries the same semantic implication that this is a compiler-only operation, while being more in line with the fence/barrier concepts already in use instd
.