Managed(?) thread-local storage

[Soni]

While developing hexchat-plugin I ran into a little issue: thread-local storage is currently global.

This is a bit of an issue and it’d be cool to have namespaced TLS.

The namespace is not thread-local, instead it gets shared between threads. But the namespace stores thread-locals efficiently. When the thread exits or the namespace gets destroyed, things get deallocated, also importantly is that there shouldn’t be any locks.

This matters when unloading hexchat plugins. I don’t want the thread locals to carry over or leak.

[cuviper]

Sounds similar to this idea:

Idea: "Ambient data"/"Current execution context"/ Was: Provide a thread-local scope with hooks for `std­։։­thread­։։­spawn`

Sometimes it’s necessary to implement a form of “implicit context” to pass a data too cumbersome to pass explicity everywhere. Eg. in slog there’s slog-scope that allows setting a “current logger”, for a duration of a function call. The called code can then retrieve and use that logger even deep down the call stack. It’s not really global variable, though it is implicitly passed around. Internally this is just implemented as thread-local Vector of objects. https://docs.rs/slog-scope/4.0.1/src/s…

[Soni]

Nope! I want thread-local storage that gets dropped when a “holder” gets dropped, and all interactions with it need to go through the “holder”.

[scottmcm]

Sounds rather like having an rc::Weak in TLS.

[Soni]

Nope! I should be able to fully deallocate it.

e.g. load plugin -> make holder -> load a second instance of plugin without loading the first -> make another holder -> use both holders at the same time, each independent of the other -> drop both holders -> unload both instances of the plugin

[scottmcm]

What does this have to do with TLS, then? Why isn’t the holder just an Arc?

[Soni]

because it’s still thread-local. if I spawned a thread, the holder would carry over, but the storage wouldn’t.