-
Notifications
You must be signed in to change notification settings - Fork 22
Closed as not planned
Closed as not planned
Copy link
Labels
T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries
Description
Proposal
Problem statement
See Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/AtomicBool.20useless.20on.20riscv.
Gist: AtomicBool uses a u8 under the hood, but not all hardware supports 8/16 bit atomics even if it support 32 bit atomics. Change the memory layout of bool to match the hardware's amo type size.
Solution sketch
+ pub type AtomicBoolType = cfg(smallest_type_supported_by_hardware)
- fn from_ptr(ptr: *mut bool) -> &AtomicBool
+ fn from_ptr(ptr: *mut AtomicBoolType) -> &AtomicBool
- fn from_mut(v: &mut bool) -> &mut AtomicBool
+ fn from_mut(v: &mut AtomicBoolType) -> &mut AtomicBool
- fn get_mut_slice(this: &mut [AtomicBool]) -> &mut [bool]
+ fn get_mut_slice(this: &mut [AtomicBool]) -> &mut [AtomicBoolType]
- fn from_mut_slice(v: &mut [bool]) -> &mut [AtomicBool]
+ fn from_mut_slice(v: &mut [AtomicBoolType]) -> &mut [AtomicBool]
Downsides
People that are relying to AtomicBool being layout compatible with bool are going to be sad.
Upside
We can be maximally efficient on all hardware while still letting people do weird transmutes since they have AtomicBoolType
.
Metadata
Metadata
Assignees
Labels
T-libs-apiapi-change-proposalA proposal to add or alter unstable APIs in the standard librariesA proposal to add or alter unstable APIs in the standard libraries