Managed(?) thread-local storage

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.

Sounds similar to this idea:

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

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


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

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


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

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.