Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

implement destructor support for thread-local variables #17572

Closed
thestinger opened this issue Sep 26, 2014 · 2 comments
Closed

implement destructor support for thread-local variables #17572

thestinger opened this issue Sep 26, 2014 · 2 comments
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code.

Comments

@thestinger
Copy link
Contributor

C++ thread_local has destructor support built on platform primitives. Rust's #[thread_local] does not since it sits above the LLVM layer. This could be feature gated, but it is an important building block for fast TLS support.
@thestinger thestinger added I-slow Issue: Problems and improvements with respect to performance of generated code. C-enhancement Category: An issue proposing an enhancement or a PR with one. A-codegen Area: Code generation labels Sep 26, 2014
@thestinger thestinger changed the title implement destructor support for global and thread-local statics implement destructor support for thread-local variables Sep 26, 2014
@thestinger thestinger mentioned this issue Sep 26, 2014
Closed
@thestinger thestinger added the E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. label Sep 27, 2014
@thestinger
Copy link
Contributor Author

Modern platforms have explicit support for this thanks to C++11, but there will need to be a slow path for older platforms. For example, OS X provides _tlv_atexit and glibc has __cxa_thread_atexit_impl. Rust needs support for selecting code based on the minimum platform version. The slow path can lock a global mutex on the first access to a TLS variable in a new thread and set up a dynamic TLS entry via an API like pthread_key_create.

The normal accesses will go through the static thread_local but dynamic TLS will take care of running destructors. The nightly Linux and OS X builds would need to use this slow path, but distribution builds will use the fast path. It's not worth trying to detect this at runtime because it will only happen once per TLS variable in a thread.

@thestinger thestinger mentioned this issue Sep 27, 2014
Closed
@pythonesque pythonesque mentioned this issue Oct 22, 2014
Closed
@alexcrichton
Copy link
Member

Added in #19094

lnicola pushed a commit to lnicola/rust that referenced this issue Jul 11, 2024
@bors
Auto merge of rust-lang#17572 - beetrees:f16-f128, r=Veykril
8cc4de6 
Add `f16` and `f128` support

Adds `f16` and `f128` support, using the `rustc_apfloat` library (also used by `rustc`) for parsing/arithmetic/displaying since the types aren't stable yet so can't be used by rust-analyzer itself.

Issue: rust-lang#17451
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot. I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @thestinger