about summary refs log tree commit diff
path: root/library/std/src/sys
AgeCommit message (Collapse)AuthorLines
2021-10-31 Windows: Resolve Command program without using the current directoryChris Denton-29/+216
2021-10-31Windows thread-local keyless dropChris Denton-1/+36
`#[thread_local]` allows us to maintain a per-thread list of destructors. This also avoids the need to synchronize global data (which is particularly tricky within the TLS callback function).
2021-10-31Rollup merge of #89068 - bjorn3:restructure_rt2, r=joshtriplettMatthias Krüger-10/+10
Restructure std::rt (part 2) A couple more cleanups on top of https://github.com/rust-lang/rust/pull/89011 Blocked on #89011
2021-10-31Make std::thread::available_concurrency support process-limited number of CPUsJosh Triplett-0/+8
Use libc::sched_getaffinity and count the number of CPUs in the returned mask. This handles cases where the process doesn't have access to all CPUs, such as when limited via taskset or similar.
2021-10-31Rollup merge of #90401 - mkroening:hermit-condvar, r=joshtriplettMatthias Krüger-2/+14
hermit: Implement Condvar::wait_timeout This implements `Condvar::wait_timeout` for the `hermit` target. See * https://github.com/hermitcore/rust/pull/2 * https://github.com/hermitcore/rust/pull/5 CC: `@stlankes`
2021-10-30Auto merge of #89174 - ChrisDenton:automatic-verbatim-paths, r=dtolnaybors-13/+174
Automatically convert paths to verbatim for filesystem operations that support it This allows using longer paths without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim then this has no effect. Fixes: #32689
2021-10-29hermit: Implement Condvar::wait_timeoutMartin Kröning-2/+14
2021-10-26Clarify platform availability of GetTempPath2Eugene Talagrand-1/+1
Windows Server 2022 is a different version from Win11, breaking precent
2021-10-23Fix typoChris Denton-1/+1
Co-authored-by: Ruslan Sayfutdinov <ruslan@sayfutdinov.com>
2021-10-23Make sure `CreateDirectoryW` works for path lengths > 247Chris Denton-1/+12
2021-10-22Add comment documenting why we can't use a simpler solutionSteven-0/+4
See #90144 for context. r? @joshtriplett
2021-10-18Update std::env::temp_dir to use GetTempPath2 on Windows when available.Eugene Talagrand-1/+7
As a security measure, Windows 11 introduces a new temporary directory API, GetTempPath2. When the calling process is running as SYSTEM, a separate temporary directory will be returned inaccessible to non-SYSTEM processes. For non-SYSTEM processes the behavior will be the same as before.
2021-10-19Rollup merge of #89941 - hermitcore:kernel, r=joshtriplettMatthias Krüger-1/+1
removing TLS support in x86_64-unknown-none-hermitkernel HermitCore's kernel itself doesn't support TLS. Consequently, the entries in x86_64-unknown-none-hermitkernel should be removed. This commit should help to finalize #89062.
2021-10-17Auto merge of #88652 - AGSaidi:linux-aarch64-should-be-actually-monotonic, ↵bors-0/+1
r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281, #56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3e183 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b0da8 tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.
2021-10-16remove compiler warningsStefan Lankes-1/+1
2021-10-16Rollup merge of #89921 - joshuaseaton:zircon-process, r=tmandryMatthias Krüger-4/+7
[fuchsia] Update process info struct The fuchsia platform is in the process of softly transitioning over to using a new value for ZX_INFO_PROCESS with a new corresponding struct. This change migrates libstd. See [fxrev.dev/510478](https://fxrev.dev/510478) and [fxbug.dev/30751](https://fxbug.dev/30751) for more detail.
2021-10-15Auto merge of #84096 - m-ou-se:windows-bcrypt-random, r=dtolnaybors-27/+14
Use BCryptGenRandom instead of RtlGenRandom on Windows. This removes usage of RtlGenRandom on Windows, in favour of BCryptGenRandom. BCryptGenRandom isn't available on XP, but we dropped XP support a while ago.
2021-10-15[fuchsia] Update process info structJoshua Seaton-4/+7
The fuchsia platform is in the process of softly transitioning over to using a new value for ZX_INFO_PROCESS with a new corresponding struct. This change migrates libstd. See fxrev.dev/510478 and fxbug.dev/30751 for more detail.
2021-10-15Use BCryptGenRandom instead of RtlGenRandom on Windows.Mara Bos-27/+14
BCryptGenRandom isn't available on XP, but we dropped XP support a while ago.
2021-10-14Rollup merge of #89433 - arlosi:stdin-fix, r=joshtriplettMatthias Krüger-9/+19
Fix ctrl-c causing reads of stdin to return empty on Windows. Pressing ctrl+c (or ctrl+break) on Windows caused a blocking read of stdin to unblock and return empty, unlike other platforms which continue to block. On ctrl-c, `ReadConsoleW` will return success, but also set `LastError` to `ERROR_OPERATION_ABORTED`. This change detects this case, and re-tries the call to `ReadConsoleW`. Fixes #89177. See issue for further details. Tested on Windows 7 and Windows 10 with both MSVC and GNU toolchains
2021-10-11Rollup merge of #89707 - clemenswasser:apply_clippy_suggestions, ↵Matthias Krüger-6/+6
r=Mark-Simulacrum Apply clippy suggestions for std
2021-10-10Auto merge of #88952 - skrap:add-armv7-uclibc, r=nagisabors-1/+5
Add new tier-3 target: armv7-unknown-linux-uclibceabihf This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org). The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward, and graciously allowed me to take it over. Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md), I volunteer to be the "target maintainer". This is my first PR to Rust itself, so I apologize if I've missed things!
2021-10-09Apply clippy suggestionsClemens Wasser-6/+6
2021-10-09Rollup merge of #87528 - :stack_overflow_obsd, r=joshtriplettGuillaume Gomez-8/+9
stack overflow handler specific openbsd change.
2021-10-08Let stack_overflow::imp::cleanup call drop_handler directlybjorn3-10/+10
instead of through the Drop impl for Handler
2021-10-07environ on macos uses directly libc which has the correct signature.David CARLIER-4/+1
2021-10-06Rollup merge of #89324 - yoshuawuyts:hardware-parallelism, r=m-ou-seManish Goregaokar-7/+7
Rename `std::thread::available_conccurrency` to `std::thread::available_parallelism` _Tracking issue: https://github.com/rust-lang/rust/issues/74479_ This PR renames `std::thread::available_conccurrency` to `std::thread::available_parallelism`. ## Rationale The API was initially named `std::thread::hardware_concurrency`, mirroring the [C++ API of the same name](https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency). We eventually decided to omit any reference to the word "hardware" after [this comment](https://github.com/rust-lang/rust/pull/74480#issuecomment-662045841). And so we ended up with `available_concurrency` instead. --- For a talk I was preparing this week I was reading through ["Understanding and expressing scalable concurrency" (A. Turon, 2013)](http://aturon.github.io/academic/turon-thesis.pdf), and the following passage stood out to me (emphasis mine): > __Concurrency is a system-structuring mechanism.__ An interactive system that deals with disparate asynchronous events is naturally structured by division into concurrent threads with disparate responsibilities. Doing so creates a better fit between problem and solution, and can also decrease the average latency of the system by preventing long-running computations from obstructing quicker ones. > __Parallelism is a resource.__ A given machine provides a certain capacity for parallelism, i.e., a bound on the number of computations it can perform simultaneously. The goal is to maximize throughput by intelligently using this resource. For interactive systems, parallelism can decrease latency as well. _Chapter 2.1: Concurrency is not Parallelism. Page 30._ --- _"Concurrency is a system-structuring mechanism. Parallelism is a resource."_ — It feels like this accurately captures the way we should be thinking about these APIs. What this API returns is not "the amount of concurrency available to the program" which is a property of the program, and thus even with just a single thread is effectively unbounded. But instead it returns "the amount of _parallelism_ available to the program", which is a resource hard-constrained by the machine's capacity (and can be further restricted by e.g. operating systems). That's why I'd like to propose we rename this API from `available_concurrency` to `available_parallelism`. This still meets the criteria we previously established of not attempting to define what exactly we mean by "hardware", "threads", and other such words. Instead we only talk about "concurrency" as an abstract resource available to our program. r? `@joshtriplett`
2021-10-06add platform support details file for armv7-unknown-linux-uclibcJonah Petri-1/+1
2021-10-06Add new target armv7-unknown-linux-uclibceabihfYannick Koehler-2/+6
Co-authored-by: Jonah Petri <jonah@petri.us>
2021-10-05Rollup merge of #88828 - FabianWolff:issue-88585, r=dtolnayManish Goregaokar-3/+13
Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlock Fixes #88585. POSIX [specifies](https://man7.org/linux/man-pages/man3/fork.3p.html) that after forking, > to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Rust's standard library does not currently adhere to this, as evidenced by #88585. The child process calls [`sys::signal()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/android.rs#L76), which on Android calls [`libc::dlsym()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/weak.rs#L101), which is [**not**](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, and in fact causes a deadlock in the example in #88585. I think the easiest solution here would be to just call `libc::sigaction()` instead, which [is](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, provides the functionality we need, and is apparently available on all Android versions because it is also used e.g. [here](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/stack_overflow.rs#L112-L114).
2021-10-04Rollup merge of #89462 - devnexen:haiku_thread_aff_build_fix, r=nagisaManish Goregaokar-6/+10
haiku thread affinity build fix
2021-10-04Rollup merge of #87631 - :solarish_upd_fs, r=joshtriplettManish Goregaokar-13/+17
os current_exe using same approach as linux to get always the full ab… …solute path
2021-10-03Rollup merge of #89472 - nagisa:nagisa/wsa-cleanup, r=dtolnayManish Goregaokar-6/+11
Only register `WSACleanup` if `WSAStartup` is actually ever called See https://github.com/rust-lang/rust/pull/85595 Fixes #85441
2021-10-03Rollup merge of #88305 - ijackson:exitstatus-debug, r=dtolnayManish Goregaokar-3/+21
Manual Debug for Unix ExitCode ExitStatus ExitStatusError These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. These misleading names appear in the `Debug` output. The `Display` impls on Unix have been improved, but the `Debug` impls are still misleading, as reported in #74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) After this change, this program ``` #![feature(exit_status_error)] fn main(){ let x = std::process::Command::new("false").status().unwrap(); dbg!(x.exit_ok()); eprintln!("x={:?}",x); } ``` produces this output ``` [src/main.rs:4] x.exit_ok() = Err( ExitStatusError( unix_wait_status( 256, ), ), ) x=ExitStatus(unix_wait_status(256)) ``` Closes #74832
2021-10-03Rollup merge of #88286 - LeSeulArtichaut:unnecessary-unsafe-block-std, r=dtolnayManish Goregaokar-2/+1
Remove unnecessary unsafe block in `process_unix` Because it's nested under this unsafe fn! This block isn't detected as unnecessary because of a bug in the compiler: #88260.
2021-10-03Automatically convert paths to verbatimChris Denton-13/+163
This allows using longer paths for filesystem operations without the user needing to `canonicalize` or manually prefix paths. If the path is already verbatim than this has no effect.
2021-10-02Run the #85441 regression test on MSVC onlySimonas Kazlauskas-3/+3
On MinGW toolchains the various features (such as function sections) necessary to eliminate dead function references are disabled due to various bugs. This means that the windows sockets library will most likely remain linked to any mingw toolchain built program that also utilizes libstd. That said, I made an attempt to also enable `function-sections` and `--gc-sections` during my experiments, but the symbol references remained, sadly.
2021-10-02Only register `WSACleanup` if `WSAStartup` is actually ever calledChristiaan Dirkx-6/+11
2021-10-02haiku thread affinity build fixDavid Carlier-6/+10
2021-10-01Call `libc::sigaction()` only on AndroidFabian Wolff-3/+14
2021-10-01Fix ctrl-c causing reads of stdin to return empty on Windows.Arlo Siemsen-9/+19
Fixes #89177
2021-09-30Rollup merge of #89306 - devnexen:haiku_ncpus, r=nagisaManish Goregaokar-1/+10
thread: implements available_concurrency on haiku
2021-09-29Auto merge of #89011 - bjorn3:restructure_rt, r=dtolnaybors-1/+1
Restructure std::rt These changes should reduce binary size slightly while at the same slightly improving performance of startup, thread spawning and `std::thread::current()`. I haven't verified if the compiler is able to optimize some of these cases already, but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location. I can remove 6f6bb16 if preferred.
2021-09-28Clean up unneeded explicit pointer castDavid Tolnay-1/+1
The reference automatically coerces to a pointer. Writing an explicit cast here is slightly misleading because that's most commonly used when a pointer needs to be converted from one pointer type to another, e.g. `*const c_void` to `*const sigaction` or vice versa.
2021-09-28Rename `std::thread::available_onccurrency` to ↵Yoshua Wuyts-7/+7
`std::thread::available_parallelism`
2021-09-28Add SOLID targetsTomoaki Kawada-0/+3740
SOLID[1] is an embedded development platform provided by Kyoto Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support for SOLID. # New Targets The following targets are added: - `aarch64-kmc-solid_asp3` - `armv7a-kmc-solid_asp3-eabi` - `armv7a-kmc-solid_asp3-eabihf` SOLID's target software system can be divided into two parts: an RTOS kernel, which is responsible for threading and synchronization, and Core Services, which provides filesystems, networking, and other things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems (more precisely, systems where only one processor core is allocated for SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is traditionally only specified at the source-code level, the ABI is unique to each implementation, which is why `asp3` is included in the target names. More targets could be added later, as we support other base kernels (there are at least three at the point of writing) and are interested in supporting other processor architectures in the future. # C Compiler Although SOLID provides its own supported C/C++ build toolchain, GNU Arm Embedded Toolchain seems to work for the purpose of building Rust. # Unresolved Questions A μITRON4 kernel can support `Thread::unpark` natively, but it's not used by this commit's implementation because the underlying kernel feature is also used to implement `Condvar`, and it's unclear whether `std` should guarantee that parking tokens are not clobbered by other synchronization primitives. # Unsupported or Unimplemented Features Most features are implemented. The following features are not implemented due to the lack of native support: - `fs::File::{file_attr, truncate, duplicate, set_permissions}` - `fs::{symlink, link, canonicalize}` - Process creation - Command-line arguments Backtrace generation is not really a good fit for embedded targets, so it's intentionally left unimplemented. Unwinding is functional, however. ## Dynamic Linking Dynamic linking is not supported. The target platform supports dynamic linking, but enabling this in Rust causes several problems. - The linker invocation used to build the shared object of `std` is too long for the platform-provided linker to handle. - A linker script with specific requirements is required for the compiled shared object to be actually loadable. As such, we decided to disable dynamic linking for now. Regardless, the users can try to create shared objects by manually invoking the linker. ## Executable Building an executable is not supported as the notion of "executable files" isn't well-defined for these targets. [1] https://solid.kmckk.com/SOLID/ [2] http://ertl.jp/ITRON/SPEC/mitron4-e.html [3] https://en.wikipedia.org/wiki/ITRON_project [4] https://toppers.jp/
2021-09-27thread: implements available_concurrency on haikuDavid Carlier-1/+10
2021-09-23Auto merge of #88587 - bdbai:fix/uwpio, r=joshtriplettbors-4/+7
Fix WinUWP std compilation errors due to I/O safety I/O safety for Windows has landed in #87329. However, it does not cover UWP specific parts and prevents all UWP targets from building. See https://github.com/YtFlow/Maple/issues/18. This PR fixes these compile errors when building std for UWP targets.
2021-09-23Reason safety for unsafe blocks for uwp stdinbdbai-0/+2
2021-09-16Replace a couple of asserts with rtassert! in rt codebjorn3-1/+1
This replaces a couple of panic locations with hard aborts. The panics can't be catched by the user anyway in these locations.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 08:37:48 +0000