about summary refs log tree commit diff
path: root/library/std/src/thread
AgeCommit message (Collapse)AuthorLines
2021-06-24Use `#[non_exhaustive]` where appropriateJacob Pratt-4/+3
Due to the std/alloc split, it is not possible to make `alloc::collections::TryReserveError::AllocError` non-exhaustive without having an unstable, doc-hidden method to construct (which negates the benefits from `#[non_exhaustive]`.
2021-06-22Auto merge of #86527 - JohnTitor:rollup-cbu78g4, r=JohnTitorbors-162/+37
Rollup of 11 pull requests Successful merges: - #85054 (Revert SGX inline asm syntax) - #85182 (Move `available_concurrency` implementation to `sys`) - #86037 (Add `io::Cursor::{remaining, remaining_slice, is_empty}`) - #86114 (Reopen #79692 (Format symbols under shared frames)) - #86297 (Allow to pass arguments to rustdoc-gui tool) - #86334 (Resolve type aliases to the type they point to in intra-doc links) - #86367 (Fix comment about rustc_inherit_overflow_checks in abs().) - #86381 (Add regression test for issue #39161) - #86387 (Remove `#[allow(unused_lifetimes)]` which is now unnecessary) - #86398 (Add regression test for issue #54685) - #86493 (Say "this enum variant takes"/"this struct takes" instead of "this function takes") Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-06-21Move `available_concurrency` implementation to `sys`Christiaan Dirkx-162/+37
2021-06-20Squashed implementation of the passAlex Vlasov-1/+1
2021-05-20std: Don't inline TLS accessor on MinGWAlex Crichton-13/+13
This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453
2021-05-19Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, ↵bors-0/+24
r=Mark-Simulacrum std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-18std: Attempt again to inline thread-local-init across cratesAlex Crichton-0/+24
Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
2021-05-07Rollup merge of #84409 - mzohreva:mz/tls-dtors-before-join, r=jethrogbDylan DPC-0/+108
Ensure TLS destructors run before thread joins in SGX The excellent test is from ```@jethrogb``` For context see: https://github.com/rust-lang/rust/pull/83416#discussion_r617282907
2021-05-06join_orders_after_tls_destructors: ensure thread 2 is launched before thread ↵Mohsen Zohrevandi-8/+9
1 enters TLS destructors
2021-05-02Change 'NULL' to 'null'Brent Kerby-1/+1
2021-04-29Use atomics in join_orders_after_tls_destructors testMohsen Zohrevandi-34/+88
std::sync::mpsc uses thread locals and depending on the order TLS dtors are run `rx.recv()` can panic when used in a TLS dtor.
2021-04-21Ensure TLS destructors run before thread joins in SGXMohsen Zohrevandi-1/+54
2021-04-21Rollup merge of #84013 - CDirkx:fmt, r=m-ou-seMara Bos-5/+5
Replace all `fmt.pad` with `debug_struct` This replaces any occurrence of: - `f.pad("X")` with `f.debug_struct("X").finish()` - `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()` This is in line with existing formatting code such as https://github.com/rust-lang/rust/blob/125505306744a0a5bb01d62337260a95d9ff8d57/library/std/src/sync/mpsc/mod.rs#L1470-L1475
2021-04-21Replace all `fmt.pad` with `debug_struct`Christiaan Dirkx-5/+5
2021-04-18fix aliasing violations in thread_local_const_initRalf Jung-1/+1
2021-04-16std: Add a variant of thread locals with const initAlex Crichton-48/+223
This commit adds a variant of the `thread_local!` macro as a new `thread_local_const_init!` macro which requires that the initialization expression is constant (e.g. could be stuck into a `const` if so desired). This form of thread local allows for a more efficient implementation of `LocalKey::with` both if the value has a destructor and if it doesn't. If the value doesn't have a destructor then `with` should desugar to exactly as-if you use `#[thread_local]` given sufficient inlining. The purpose of this new form of thread locals is to precisely be equivalent to `#[thread_local]` on platforms where possible for values which fit the bill (those without destructors). This should help close the gap in performance between `thread_local!`, which is safe, relative to `#[thread_local]`, which is not easy to use in a portable fashion.
2021-04-11Clarify the guarantees that ThreadId does and doesn't make.Laurence Tratt-4/+7
The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
2021-03-27Use DebugStruct::finish_non_exhaustive() in std.Mara Bos-1/+4
2021-03-21Use io::Error::new_const everywhere to avoid allocations.Mara Bos-5/+5
2021-02-10Rollup merge of #79849 - Digital-Chaos:sleep-zero, r=m-ou-seYuki Okushi-0/+9
Clarify docs regarding sleep of zero duration Clarify that the behaviour of sleep() when given a duration of zero is actually platform specific.
2021-01-15Update library/std/src/thread/mod.rs James Wright-0/+1
Fix link reference Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2021-01-15Clarify difference between unix/windows behaviourJames Wright-0/+8
Updated to specify the underlying syscalls
2020-12-18Recommend panic::resume_unwind instead of panicking.Corey Farwell-7/+12
Fixes https://github.com/rust-lang/rust/issues/79950.
2020-11-22Drop support for cloudabi targetsLzu Tao-1/+0
2020-11-10Merge set_panic and set_print into set_output_capture.Mara Bos-3/+3
There were no use cases for setting them separately. Merging them simplifies some things.
2020-11-07Convert a bunch of intra-doc linksCamelid-2/+1
2020-10-22Capture output from threads spawned in testsTyler Mandry-0/+5
Fixes #42474.
2020-10-16Add std::thread::available_concurrencyYoshua Wuyts-0/+163
2020-10-02Rollup merge of #77147 - fusion-engineering-forks:static-mutex, r=dtolnayYuki Okushi-3/+2
Split sys_common::Mutex in StaticMutex and MovableMutex. The (unsafe) `Mutex` from `sys_common` had a rather complicated interface. You were supposed to call `init()` manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if `destroy()` should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this `Mutex`, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither `init()` nor `destroy()` are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the `LockGuard`, never with `raw_lock`. 2. As a `Box`ed variable. In this case, both `init()` and `destroy()` are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this `Mutex` type into two types matching the two use cases: `StaticMutex` and `MovableMutex`. The interface of both new types is now both safer and simpler. The first one does not call nor expose `init`/`destroy`, and the second one calls those automatically in its `new()` and `Drop` functions. Also, the locking functions of `MovableMutex` are no longer unsafe. --- This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. ~~(But that's blocked on #76932 for now.)~~ (See #77380.)
2020-09-27Move thread parker to sys_common.Mara Bos-224/+1
2020-09-27Add notes about memory ordering to futex parker implementation.Mara Bos-0/+20
2020-09-27Move linux-specific futex code into `sys` module.Mara Bos-36/+3
2020-09-27Fix warning.Mara Bos-1/+1
2020-09-27Mark unpark() as #[inline].Mara Bos-0/+2
2020-09-27Add fast futex-based thread parker for Linux.Mara Bos-123/+231
2020-09-27Move thread parker to a separate module.Mara Bos-112/+142
2020-09-27Split sys_common::Mutex in StaticMutex and MovableMutex.Mara Bos-3/+2
The (unsafe) Mutex from sys_common had a rather complicated interface. You were supposed to call init() manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if destroy() should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this Mutex, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither init() nor destroy() are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the LockGuard, never with raw_lock. 2. As a Boxed variable. In this case, both init() and destroy() are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. The interface of both new types is now both safer and simpler. The first one does not call nor expose init/destroy, and the second one calls those automatically in its new() and Drop functions. Also, the locking functions of MovableMutex are no longer unsafe.
2020-09-26Auto merge of #74225 - poliorcetics:std-thread-unsafe-op-in-unsafe-fn, ↵bors-44/+127
r=joshtriplett Std/thread: deny unsafe op in unsafe fn Partial fix of #73904. This encloses `unsafe` operations in `unsafe fn` in `libstd/thread`. `@rustbot` modify labels: F-unsafe-block-in-unsafe-fn
2020-09-22Update library functions with stability attributesDylan MacKenzie-0/+2
This may not be strictly minimal, but all unstable functions also need a `rustc_const_unstable` attribute.
2020-09-21Fix missing unsafe block for target arch wasm32Alexis Bourget-3/+10
2020-09-21Fix accordingly to reviewAlexis Bourget-22/+20
2020-09-21Improve some SAFETY comments following suggestionsAlexis Bourget-6/+17
2020-09-21Finished documenting all unsafe op inside unsafe fnAlexis Bourget-5/+17
2020-09-21Deny unsafe op in unsafe fns without the unsafe keyword, first part for ↵Alexis Bourget-36/+91
std/thread
2020-09-03Use inline(never) instead of coldHoward Su-3/+2
inline(never) is better way to avoid optimizer to inline the function instead of cold.
2020-08-31std: move "mod tests/benches" to separate filesLzu Tao-470/+465
Also doing fmt inplace as requested.
2020-08-20Move to intra doc links for std::thread documentationAlexis Bourget-87/+40
2020-07-29Disallow missing unsafe blocks in unsafe fn in panicking.rsAlexis Bourget-1/+5
This adds SAFETY comments where necessary, explaining the preconditions and how they are respected.
2020-07-27mv std libs to library/mark-0/+2534
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 04:50:27 +0000