Managed(?) thread-local storage


#1

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.


#2

Sounds similar to this idea:


#3

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”.


#4

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


#5

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


#6

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


#7

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