rust/src/libstd/thread, branch 1.32.0

Fix small typo in comment

2018-11-27T17:57:55+00:00

fix various typos in doc comments

2018-11-13T19:45:31+00:00

Rollup merge of #55597 - alexcrichton:thread-local-inner, r=KodrAus

2018-11-06T09:08:03+00:00

std: Enable usage of `thread_local!` through imports The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.

std: Enable usage of `thread_local!` through imports

2018-11-01T21:17:39+00:00

The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.

std: Improve codegen size of accessing TLS

2018-11-01T17:46:31+00:00

Some code in the TLS implementation in libstd stores `Some(val)` into an `&mut Option` (effectively) and then pulls out `&T`, but it currently uses `.unwrap()` which can codegen into a panic even though it can never panic. With sufficient optimizations enabled (like LTO) the compiler can see through this but this commit helps it along in normal mode (`--release` with Cargo by default) to avoid codegen'ing the panic path. This ends up improving the optimized codegen on wasm by ensuring that a call to panic pulling in more file size doesn't stick around.

thread::unpark: Avoid notifying with mutex locked.

2018-10-30T22:54:35+00:00

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.

Auto merge of #55043 - oliver-giersch:unchecked_thread_spawning, r=alexcrichton

2018-10-28T21:34:12+00:00

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>` 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`. 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.

Rollup merge of #54646 - vn971:fix_std_thread_sleep, r=frewsxcv

2018-10-18T04:54:42+00:00

improve documentation on std::thread::sleep

adds tracking issue number

2018-10-16T20:42:14+00:00

Merge pull request #5 from oliver-giersch/master

2018-10-15T12:38:34+00:00

sync with upstream