about summary refs log tree commit diff
path: root/src/libstd/sys/common/thread_info.rs
AgeCommit message (Collapse)AuthorLines
2015-01-02rollup merge of #20354: alexcrichton/second-pass-thread_localAlex Crichton-2/+3
Conflicts: src/libstd/sys/common/thread_info.rs
2014-12-31std: unbox closures used in function argumentsJorge Aparicio-2/+2
2014-12-31std: Second pass stabilization for thread_localAlex Crichton-2/+3
This commit performs a second pass over the `std::thread_local` module. Most of the functionality remains explicitly unstable, but the specific actions taken were: * `thread_local` is now stable * `thread_local!` is now stable * `thread_local::Key` is now stable * `thread_local::Key::with` is now stable * `thread_local::Key::destroyed` is deprecated in favor of a more general `state` function * `thread_local::Key::state` was added to query the three states that a key can be in: uninitialized, valid, or destroyed. This function, and the corresponding `State` enum, are both marked unstable as we may wish to expand it later on. * `thread_local::scoped` is entirely unstable. There hasn't been a whole lot of usage of this module in the standard distribution, so it remains unstable at this time. Note that while the structure `Key` is marked stable, it is currently forced to expose all of its implementation details due to the use of construction-via-macro. The use of construction-via-macro is currently required in order to place the `#[thread_local]` attribute on static in a platform-specific manner. These stability attributes were assigned assuming that it will be acceptable to tweak the implementation of `Key` in the future.
2014-12-18Rebasing fixes.Aaron Turon-1/+1
2014-12-18std: Move the panic flag to its own thread localAlex Crichton-11/+0
This flag is somewhat tied to the `unwind` module rather than the `thread_info` module, so this commit moves it into that module as well as allowing the same OS thread to call `unwind::try` multiple times. Previously once a thread panicked its panic flag was never reset, even after exiting the panic handler.
2014-12-18Revise std::thread API to join by defaultAaron Turon-0/+5
This commit is part of a series that introduces a `std::thread` API to replace `std::task`. In the new API, `spawn` returns a `JoinGuard`, which by default will join the spawned thread when dropped. It can also be used to join explicitly at any time, returning the thread's result. Alternatively, the spawned thread can be explicitly detached (so no join takes place). As part of this change, Rust processes now terminate when the main thread exits, even if other detached threads are still running, moving Rust closer to standard threading models. This new behavior may break code that was relying on the previously implicit join-all. In addition to the above, the new thread API also offers some built-in support for building blocking abstractions in user space; see the module doc for details. Closes #18000 [breaking-change]
2014-12-18Avoid .take().unwrap() with FnOnce closuresAlex Crichton-3/+2
2014-12-18Fallout from new thread APIAaron Turon-9/+6
2014-12-18Revise rt::unwindAaron Turon-6/+24
2014-12-18Introduce std::threadAaron Turon-0/+60
Also removes: * `std::task` * `std::rt::task` * `std::rt::thread` Notes for the new API are in a follow-up commit. Closes #18000