-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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.
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
std: make thread::current
available in all thread_local!
destructors
#127912
Conversation
This comment has been minimized.
This comment has been minimized.
7dd342e
to
f4486ee
Compare
This comment has been minimized.
This comment has been minimized.
f4486ee
to
fa1cb86
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #127924) made this pull request unmergeable. Please resolve the merge conflicts. |
fa1cb86
to
4459a4f
Compare
The Miri subtree was changed cc @rust-lang/miri |
4459a4f
to
d6777a9
Compare
☔ The latest upstream changes (presumably #128213) made this pull request unmergeable. Please resolve the merge conflicts. |
Needs a rebase, but I think it looks ok, so @rustbot author |
d6777a9
to
cfbd250
Compare
T'was just a few imports and an @bors r=cupiver |
…cupiver std: make `thread::current` available in all `thread_local!` destructors ... and thereby allow the panic runtime to always print the right thread name. This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there. Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS). The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing rust-lang#111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
…cupiver std: make `thread::current` available in all `thread_local!` destructors ... and thereby allow the panic runtime to always print the right thread name. This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there. Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS). The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing rust-lang#111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
…piver std: make `thread::current` available in all `thread_local!` destructors ... and thereby allow the panic runtime to always print the right thread name. This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by `std` have run. Unfortunately, this doesn't affect foreign TLS destructors, `thread::current` will still panic there. Additionally, the thread ID returned by `current_id` will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS). The mechanisms I added for this (`local_pointer` and `thread_cleanup`) will also allow finally fixing rust-lang#111272 by moving the signal stack to a similar runtime-cleanup TLS variable.
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
b1e383b
to
a71ba0c
Compare
Another import error... |
Just fixing my name for the record... @bors r- |
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (fd1f8aa): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (primary -0.5%, secondary -0.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 1.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary -0.2%, secondary -0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 772.767s -> 771.674s (-0.14%) |
Fixes rust-lang#111272. With rust-lang#127912 merged, we now have all the infrastructure in place to support stack overflow detection in TLS destructors. This was not possible before because the signal stack was freed in the thread main function, thus a SIGSEGV afterwards would immediately crash. And on platforms without native TLS, the guard page address was stored in an allocation freed in a TLS destructor, so would not be available. rust-lang#127912 introduced the `local_pointer` macro which allows storing a pointer-sized TLS variable without allocation and the `thread_cleanup` runtime function which is called after all other code managed by the Rust runtime. This PR simply moves the signal stack cleanup to the end of `thread_cleanup` and uses `local_pointer` to store every necessary variable. And so, everything run under the Rust runtime is now properly protected against stack overflows.
... and thereby allow the panic runtime to always print the right thread name.
This works by modifying the TLS destructor system to schedule a runtime cleanup function after all other TLS destructors registered by
std
have run. Unfortunately, this doesn't affect foreign TLS destructors,thread::current
will still panic there.Additionally, the thread ID returned by
current_id
will now always be available, even inside the global allocator, and will not change during the lifetime of one thread (this was previously the case with key-based TLS).The mechanisms I added for this (
local_pointer
andthread_cleanup
) will also allow finally fixing #111272 by moving the signal stack to a similar runtime-cleanup TLS variable.