The `thread::scoped` function will never be stabilized as-is and the API will
likely change significantly if it does, so this function is deprecated for
removal.
Currently the compiler has no knowledge of `#[thread_local]` which forces users
to take on two burdens of unsafety:
* The lifetime of the borrow of a `#[thread_local]` static is **not** `'static`
* Types in `static`s are required to be `Sync`
The thread-local modules mostly curb these facets of unsafety by only allowing
very limited scopes of borrows as well as allowing all types to be stored in a
thread-local key (regardless of whether they are `Sync`) through an `unsafe
impl`.
Unfortunately these measures have the consequence of being able to take the
address of the key itself and send it to another thread, allowing the same key
to be accessed from two different threads. This is clearly unsafe, and this
commit fixes this problem with the same trick used by `LocalKey`, which is to
have an indirect function call to find the address of the *current thread's*
thread local. This way the address of thread local keys can safely be sent among
threads as their lifetime truly is `'static`.
This commit will reduce the performance of cross-crate scoped thread locals as
it now requires an indirect function call, but this can likely be overcome in a
future commit.
Closes#25894
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes#24874
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes#24874
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
Inspecting the current thread's info may not always work due to the TLS value
having been destroyed (or is actively being destroyed). The code for printing
a panic message assumed, however, that it could acquire the thread's name
through this method.
Instead this commit propagates the `Option` outwards to allow the
`std::panicking` module to handle the case where the current thread isn't
present.
While it solves the immediate issue of #24313, there is still another underlying
issue of panicking destructors in thread locals will abort the process.
Closes#24313
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
Much of this code hasn't been updated in quite some time and this commit does a
small audit of the functionality:
* Implementation functions now centralize all functionality on a locally defined
`Thread` type.
* The `detach` method has been removed in favor of a `Drop` implementation. This
notably fixes leaking thread handles on Windows.
* The `Thread` structure is now appropriately annotated with `Send` and `Sync`
automatically on Windows and in a custom fashion on Unix.
* The unsafety of creating a thread has been pushed out to the right boundaries
now.
Closes#24442
This commit removes all the old casting/generic traits from `std::num` that are
no longer in use by the standard library. This additionally removes the old
`strconv` module which has not seen much use in quite a long time. All generic
functionality has been supplanted with traits in the `num` crate and the
`strconv` module is supplanted with the [rust-strconv crate][rust-strconv].
[rust-strconv]: https://github.com/lifthrasiir/rust-strconv
This is a breaking change due to the removal of these deprecated crates, and the
alternative crates are listed above.
[breaking-change]
`thread::spawn` was previously restricted to closures that return `()`,
which limited the utility of joining on a spawned thread. However, there
is no reason for this restriction, and this commit allows arbitrary
return types.
Since it introduces a type parameter to `JoinHandle`, it's technically
a:
[breaking-change]
However, no code is actually expected to break.
Issue #24292 demonstrates that the `scoped` API as currently offered can
be memory-unsafe: the `JoinGuard` can be moved into a context that will
fail to execute destructors prior to the stack frame being popped (for
example, by creating an `Rc` cycle).
This commit reverts the APIs to `unstable` status while a long-term
solution is worked out.
(There are several possible ways to address this issue; it's not a
fundamental problem with the `scoped` idea, but rather an indication
that Rust doesn't currently provide a good way to ensure that
destructors are run within a particular stack frame.)
[breaking-change]
Make the structure more amenable to what rustdoc is expecting to ensure that
everything renders all nice and pretty in the output.
Closes#23705Closes#23910
This commit renames and stabilizes:
* `Condvar::wait_timeout_ms` (renamed from `wait_timeout`)
* `thread::park_timeout_ms` (renamed from `park_timeout`)
* `thread::sleep_ms` (renamed from `sleep`)
In each case, the timeout is taken as a `u32` number of milliseconds,
rather than a `Duration`.
These functions are likely to be deprecated once a stable form of
`Duration` is available, but there is little cost to having these named
variants around, and it's crucial functionality for 1.0.
[breaking-change]
r? @alexcrichton
cc @sfackler @carllerche
This commit renames and stabilizes:
* `Condvar::wait_timeout_ms` (renamed from `wait_timeout`)
* `thread::park_timeout_ms` (renamed from `park_timeout`)
* `thread::sleep_ms` (renamed from `sleep`)
In each case, the timeout is taken as a `u32` number of milliseconds,
rather than a `Duration`.
These functions are likely to be deprecated once a stable form of
`Duration` is available, but there is little cost to having these named
variants around, and it's crucial functionality for 1.0.
[breaking-change]
for `Box<FnBox()>`. I found the alias was still handy because it is
shorter than the fully written type.
This is a [breaking-change]: convert code using `Invoke` to use `FnBox`,
which is usually pretty straight-forward. Code using thunk mostly works
if you change `Thunk::new => Box::new` and `foo.invoke(arg)` to
`foo(arg)`.
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
[breaking-change]
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
This commit provides a safe, but unstable interface for the `try` functionality
of running a closure and determining whether it panicked or not.
There are two primary reasons that this function was previously marked `unsafe`:
1. A vanilla version of this function exposes the problem of exception safety by
allowing a bare try/catch in the language. It is not clear whether this
concern should be directly tied to `unsafe` in Rust at the API level. At this
time, however, the bounds on `ffi::try` require the closure to be both
`'static` and `Send` (mirroring those of `thread::spawn`). It may be possible
to relax the bounds in the future, but for now it's the level of safety that
we're willing to commit to.
2. Panicking while panicking will leak resources by not running destructors.
Because panicking is still controlled by the standard library, safeguards
remain in place to prevent this from happening.
The new API is now called `catch_panic` and is marked as `#[unstable]` for now.
This attribute has been deprecated in favor of #[should_panic]. This also
updates rustdoc to no longer accept the `should_fail` directive and instead
renames it to `should_panic`.
This commit provides a safe, but unstable interface for the `try` functionality
of running a closure and determining whether it panicked or not.
There are two primary reasons that this function was previously marked `unsafe`:
1. A vanilla version of this function exposes the problem of exception safety by
allowing a bare try/catch in the language. It is not clear whether this
concern should be directly tied to `unsafe` in Rust at the API level. At this
time, however, the bounds on `ffi::try` require the closure to be both
`'static` and `Send` (mirroring those of `thread::spawn`). It may be possible
to relax the bounds in the future, but for now it's the level of safety that
we're willing to commit to.
2. Panicking while panicking will leak resources by not running destructors.
Because panicking is still controlled by the standard library, safeguards
remain in place to prevent this from happening.
The new API is now called `catch_panic` and is marked as `#[unstable]` for now.
This commit implements [RFC
909](https://github.com/rust-lang/rfcs/pull/909):
The `std::thread_local` module is now deprecated, and its contents are
available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and
`ScopedKey`.
The macros remain exactly as they were, which means little if any code
should break. Nevertheless, this is technically a:
[breaking-change]
Closes#23547
