about summary refs log tree commit diff
path: root/src/libstd/sys_common/thread_local.rs
AgeCommit message (Collapse)AuthorLines
2020-07-12rename fast_thread_local -> thread_local_dtor; thread_local -> thread_local_keyRalf Jung-304/+0
2019-12-22Format the worldMark Rousskov-16/+19
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-1/+1
2019-02-28libstd => 2018Taiki Endo-4/+4
2018-12-25Remove licensesMark Rousskov-10/+0
2018-08-08avoid using the word 'initialized' to talk about that non-reentrant-capable ↵Ralf Jung-1/+1
state of the mutex
2018-08-06actually, reentrant uninitialized mutex acquisition is outright UBRalf Jung-3/+2
2018-08-06clarify partially initialized Mutex issuesRalf Jung-0/+3
2018-06-17libstd: add an RAII utility for sys_common::mutex::MutexNODA, Kai-2/+1
Signed-off-by: NODA, Kai <nodakai@gmail.com>
2018-04-13std: Minimize size of panicking on wasmAlex Crichton-2/+2
This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2017-12-06Update miri to rustc changesOliver Schneider-1/+1
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-1/+1
Like #43008 (f668999), but _much more aggressive_.
2017-06-24Auto merge of #42687 - alexcrichton:windows-tls, r=sfacklerbors-1/+34
rustc: Enable #[thread_local] for Windows I think LLVM has had support for quite some time now for this, we just never got around to testing it out and binding it. We've had some trouble landing this in the past I believe, but it's time to try again! This commit flags the `#[thread_local]` attribute as being available for Windows targets and adds an implementation of `register_dtor` in the `thread::local` module to ensure we can destroy these keys. The same functionality is implemented in clang via a function called `__tlregdtor` (presumably provided in some Windows runtime somewhere), but this function unfortunately does not take a data pointer (just a thunk) which means we can't easily call it. For now destructors are just run in the same way the Linux fallback is implemented, which is just keeping track via a single OS-based TLS key.
2017-06-23rustc: Enable #[thread_local] for WindowsAlex Crichton-1/+34
I think LLVM has had support for quite some time now for this, we just never got around to testing it out and binding it. We've had some trouble landing this in the past I believe, but it's time to try again! This commit flags the `#[thread_local]` attribute as being available for Windows targets and adds an implementation of `register_dtor` in the `thread::local` module to ensure we can destroy these keys. The same functionality is implemented in clang via a function called `__tlregdtor` (presumably provided in some Windows runtime somewhere), but this function unfortunately does not take a data pointer (just a thunk) which means we can't easily call it. For now destructors are just run in the same way the Linux fallback is implemented, which is just keeping track via a single OS-based TLS key.
2017-06-23Removed as many "```ignore" as possible.kennytm-4/+4
Replaced by adding extra imports, adding hidden code (`# ...`), modifying examples to be runnable (sorry Homura), specifying non-Rust code, and converting to should_panic, no_run, or compile_fail. Remaining "```ignore"s received an explanation why they are being ignored.
2017-05-05std: Avoid locks during TLS destruction on WindowsAlex Crichton-15/+22
Gecko recently had a bug reported [1] with a deadlock in the Rust TLS implementation for Windows. TLS destructors are implemented in a sort of ad-hoc fashion on Windows as it doesn't natively support destructors for TLS keys. To work around this the runtime manages a list of TLS destructors and registers a hook to get run whenever a thread exits. When a thread exits it takes a look at the list and runs all destructors. Unfortunately it turns out that there's a lock which is held when our "at thread exit" callback is run. The callback then attempts to acquire a lock protecting the list of TLS destructors. Elsewhere in the codebase while we hold a lock over the TLS destructors we try to acquire the same lock held first before our special callback is run. And as a result, deadlock! This commit sidesteps the issue with a few small refactorings: * Removed support for destroying a TLS key on Windows. We don't actually ever exercise this as a public-facing API, and it's only used during `lazy_init` during racy situations. To handle that we just synchronize `lazy_init` globally on Windows so we never have to call `destroy`. * With no need to support removal the global synchronized `Vec` was tranformed to a lock-free linked list. With the removal of locks this means that iteration no long requires a lock and as such we won't run into the deadlock problem mentioned above. Note that it's still a general problem that you have to be extra super careful in TLS destructors. For example no code which runs a TLS destructor on Windows can call back into the Windows API to do a dynamic library lookup. Unfortunately I don't know of a great way around that, but this at least fixes the immediate problem that Gecko was seeing which is that with "well behaved" destructors the system would still deadlock! [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1358151
2016-11-01std: Move sys_common to libstd/sys_commonBrian Anderson-0/+270
Make the directory structure reflect the module structure. I've always found the existing structure confusing.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-13 15:24:02 +0000