-
Notifications
You must be signed in to change notification settings - Fork 203
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
MSRV(future): Use std::{sync::OnceLock/io::Read}` to eliminate more unsafe code & once_cell dependency. #485
Conversation
// https://github.com/rust-lang/rust/issues/126239. | ||
static FILE: OnceLock<File> = OnceLock::new(); | ||
let mut file: &File = FILE.get_or_try_init(init)?; | ||
file.read_buf_exact(BorrowedBuf::from(dest).unfilled()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we should consider changing the internal getrandom_inner(dest: &mut [MaybeUninit<u8>])
API to take BorrowedCursor/BorrowedBuf instead. util_libc::sys_read_exact could then be changed similarly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea to eventually migrate to BorrowedBuf
, but until it's stabilized, I don't think we should change the current approach.
ad02284
to
7b8173e
Compare
Remove src/lazy.rs. `lazy::LazyBool` had "Last to win the race" semantics; when multiple threads see an uninitialized LazyBool, all of them will calculate a value. As they finish, each one will overwrite the value set by the previous thread. If two threads calculate different values for the boolean, then the value of the boolean can change during the period where the threads are racing. This doesn't seem to be a huge issue with the way it is currently used, but it is hard to reason about. `once_cell::race::OnceBool` has "first to win the race" semantics. When multiple threads see an uninitialized OnceBool, all of them will calculate a vlaue. The first one to finish will write its value; the rest will have their work ignored. Thus there is never any change in the stored value at any point. This is much easier to reason about. The different semantics come down to the fact that once_cell uses `AtomicUsize::compare_exchange` whereas lazy.rs was using `AtomicUsize::store`.
For now, still use `libc::{poll,read}`. But use `File::open` to open the files, instead of using `DropGuard`. While doing this, switch to the `RawFd` type alias from `libc::c_int`.
pthreads mutexes are not safe to move. While it is very unlikely that the mutex we create will ever be moved, we don't actively do anything to actively prevent it from being moved. (libstd, when it used/uses pthreads mutexes, would box them to prevent them from being moved.) Also, now on Linux and Android (and many other targets for which we don't use use_std), libstd uses futexes instead of pthreads mutexes. Thus using libstd's Mutex will be more efficient and avoid adding an often-otherwise-unnecessary libpthreads dependency on these targets. * Linux, Android: Futex [1]. * Haiku, Redox, NTO, AIX: pthreads [2]. * others: not using `use_file`. This will not affect our plans for *-*-linux-none, since we don't plan to use `use_file` for it. This breaks 32-bit x86 QNX Neutrino, which doesn't have libstd because the target itself is abandoned [3]. the other QNX Neutrino targets didn't get libstd support until Rust 1.69, so this effectively raises the MSRV for them to 1.69. I tried to use `std::sync::Once` to avoid adding an external dependency but it doesn't support fallible initialization. `OnceLock` wasn't added until 1.70, and even then `OnceLock::get_or_try_init` is still unstable.
Replace some unsafe code with safe code. Eliminate the libc dependency on non-Android/Linux targets that use use_file.
Closing this since it is just a PoC and can't be merged for a long time, if ever. |
With these changes, the only
unsafe
in use_file is Linux/Android's use oflibc::poll
.This cannot be merged as-is because it depends on unstable features. This PR is intended to demonstrate potential future directions.