| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Enable some timeouts in SGX platform
This would partially resolve https://github.com/fortanix/rust-sgx/issues/31
cc @jethrogb and @Goirad
|
|
|
|
This would partially resolve
https://github.com/fortanix/rust-sgx/issues/31
|
|
|
|
|
|
Fixes clippy::{cone_on_copy, filter_next, redundant_closure, single_char_pattern, len_zero,redundant_field_names, useless_format, identity_conversion, map_clone, into_iter_on_ref, needless_return, option_as_ref_deref, unused_unit, unnecessary_mut_passed}
|
|
|
|
As discussed in #67939, this allows turning Option<ThreadId> into Option<NonZeroU64> which
can then be stored inside an AtomicU64.
|
|
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a stylistic change to libstd to reduce the number of checks of
`feature = "backtrace"` now that we unconditionally depend on the
`backtrace` crate and rely on it having an empty implementation.
otherwise.
|
|
|
|
|
|
Stack size of 10 **bytes** does not make any sense: the minimal possible stack size is greater anyway.
|
|
|
|
|
|
Include id in Thread's Debug implementation
Since Rust 1.19.0, `id` is a stable method, so there is no reason to not include it in Debug implementation.
|
|
Since Rust 1.19.0, id is a stable method, so there is no reason to
not include it in Debug implementation.
|
|
SGX target: fix std unit tests
This fixes some tests and some code in the SGX sys implementation to make the `std` unit test suite pass.
#59009 must be merged first.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
expand thread::park explanation
Cc @carllerche @parched @stjepang
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This means when the other thread wakes it can continue right away
instead of having to wait for the mutex.
Also add some comments explaining why the mutex needs to be locked in
the first place.
|
|
Unchecked thread spawning
# Summary
Add an unsafe interface for spawning lifetime-unrestricted threads for
library authors to build less-contrived, less-hacky safe abstractions
on.
# Motivation
So a few years back scoped threads were entirely removed from the Rust
stdlib, the reason being that it was possible to leak the scoped thread's
join guards without resorting to unsafe code, which meant the concept
was not completely safe, either.
Only a maximally-restrictive safe API for thread spawning was kept in the
stdlib, that requires `'static` lifetime bounds on both the thread closure
and its return type.
A number of 3rd party libraries sprung up to offer their implementations
for safe scoped threads implementations.
These work by essentially hiding the join guards from the user, thus
forcing them to join at the end of an (internal) function scope.
However, since these libraries have to use the maximally restrictive
thread spawning API, they have to resort to some very contrived manipulations
and subversions of Rust's type system to basically achieve what this commit does
with some minimal restructuring of the current code and exposing a new unsafe
function signature for spawning threads without lifetime restrictions.
Obviously this is unsafe, but its main use would be to allow library authors
to write safe abstractions with and around it.
To further illustrate my point, here's a quick summary of the hoops that,
for instance `crossbeam`, has to jump through to spawn a lifetime unrestricted
thread, all of which would not be necessary if an unsafe API existed as part
of the stdlib:
1. Allocate an `Arc<Option<T>>` on the heap where the result with type
`T: 'a` will go (in practice requires `Mutex` or `UnsafeCell` as well).
2. Wrap the desired thread closure with lifetime bound `'a` into another
closure (also `..: 'a`) that returns `()`, executes the inner closure and
writes its result into the pre-allocated `Option<T>`.
3. Box the wrapping closure, cast it to a trait object (`FnBox`) and
(unsafely) transmute its lifetime bound from `'a` to `'static`.
So while this new `spawn_unchecked` function is certainly not very relevant
for general use, since scoped threads are so common I think it makes sense
to expose an interface for libraries implementing these to build on.
The changes implemented are also very minimal: The current `spawn` function
(which internally contains unsafe code) is moved into an unsafe `spawn_unchecked`
function, which the safe function then wraps around.
# Issues
- ~~so far, no documentation for the new function (yet)~~
- the name of the function might be controversial, as `*_unchecked` more commonly
indicates that some sort of runtime check is omitted (`unrestricted` may be
more fitting)
- if accepted, it might make sense to add a freestanding `thread::spawn_unchecked`
function similar to the current `thread::spawn` for convenience.
|
|
improve documentation on std::thread::sleep
|
|
|
|
sync with upstream
|
|
|
|
|
|
|
|
|
|
generic lifetime bound `'a` can be inferred.
|
