about summary refs log tree commit diff
path: root/src/libstd/sys/common/thread_info.rs
AgeCommit message (Collapse)AuthorLines
2015-08-11Register new snapshotsAlex Crichton-3/+0
* Lots of core prelude imports removed * Makefile support for MSVC env vars and Rust crates removed * Makefile support for morestack removed
2015-08-03syntax: Implement #![no_core]Alex Crichton-1/+2
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The `#![no_std]` attribute now injects `extern crate core` at the top of the crate as well as the libcore prelude into all modules (in the same manner as the standard library's prelude). The `#![no_core]` attribute disables both std and core injection. [rfc]: https://github.com/rust-lang/rfcs/pull/1184
2015-07-21std: Be resilient to failure in pthread_getattr_npAlex Crichton-4/+4
This can fail on linux for various reasons, such as the /proc filesystem not being mounted. There are already many cases where we can't set up stack guards, so just don't worry about this case and communicate that no guard was enabled. I've confirmed that this allows the compiler to run in a chroot without /proc mounted. Closes #22642
2015-04-27std: Don't assume thread::current() works on panicAlex Crichton-6/+5
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
2015-03-26Mass rename uint/int to usize/isizeAlex Crichton-3/+3
Now that support has been removed, all lingering use cases are renamed.
2015-03-23Implement RFC 909: move thread_local into threadAaron Turon-2/+2
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
2015-03-12std: Remove #[allow] directives in sys modulesAlex Crichton-7/+3
These were suppressing lots of interesting warnings! Turns out there was also quite a bit of dead code.
2015-02-17Fallout from stabilizationAaron Turon-2/+2
2015-02-08Move native thread name setting from thread_info to Thread, fixes #21911Vojtech Kral-4/+0
2015-02-05cleanup: replace `as[_mut]_slice()` calls with deref coercionsJorge Aparicio-1/+1
2015-01-28Thread native name setting, fix #10302Vojtech Kral-0/+4
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