-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Allow the global alloc one TLS slot with a destructor #143761
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
base: master
Are you sure you want to change the base?
Conversation
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
I've added a test which uses a Writing such an allocator only works if we guarantee not to touch the
Can we change/mitigate these things so that Just to clarify, the current behavior of this PR is safe, you just get a |
cc @joboet, since you've done a lot in this area did you want to take this? I'd be interested in your input even if not. |
Sure, I can take this. Though I'm not convinced that the current approach is a good idea – just one TLS variable with a destructor seems like an arbitrary limit and will hinder the compositionality of allocators. And this also doesn't work on platforms like GNU/Windows, where the TLS storage is always allocated. I think there are two better solutions:
|
This PR doesn't prevent better solutions from being adopted later - it's already a huge improvement over the status quo (where an allocator is unable to register any kind of per-thread cleanup natively in Rust).
This solution (and limitation) is only for the global allocator, which is already not composable. Only a single one may be set.
I don't quite follow, why would this not work on GNU/Windows? |
This is an improvement over #116402, which fixed an unsoundness by simply disallowing the global allocator from creating any thread-local variables with destructors. Instead of doing that, with this PR the global allocator is allowed to create exactly one thread-local variable with a destructor.
This is actually already a huge improvement over the status quo, as a single thread-local variable with a destructor is sufficient to store arbitrary amounts of thread-local data while allowing cleanup on thread exit.