Skip to content
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

use_file: Use std::fs::File instead of libc and once_cell::sync::OnceCell instead of pthreads mutex #481

Closed
wants to merge 2 commits into from

Conversation

briansmith
Copy link
Contributor

See the individual commit messages for details.

} else {
get_fd_locked()
}
File::open(FILE_PATH).map_err(map_io_error)
Copy link
Member

@newpavlov newpavlov Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep the libc-based open_readonly function. This code is less transparent and IIUC involves adding null termination to the file path. We have to use libc for reading, so using it for opening should be fine as well.

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.
@newpavlov
Copy link
Member

Closing it in favor of #490, but we may reconsider it before v0.3 release.

@newpavlov newpavlov closed this Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants