Hacker News Reader

When you declare a `static char *p;', how do you even know in which address of memory it is going to end up ?? How do you know what will happen if another compilation unit declares another variable of the same name? Another static library? Another dynamic library? What about initialization, what about other constructors that may read memory before main() runs? What about injected threads that are started before that? Madness, I tell you, absolute and utter madness.

The initialisation model in c++ is totally and utterly broken and indecipherable. That doesn’t stop me from doing vector<int> foo = {1,2, 3};

Avoiding thread locals due to dynamic libraries being bad is justified but still doesn't feel like the right tradeoff.

> When you declare a "static __thread char p", how do you know that for instance this is located at the 123th word of the per-thread area?

Believe it or not, it's exactly the same way it knows that "static char p" is located at the 123rd word of the data section: The linker does it!

> What if that declaration is on a dynamic library, which was loaded late (dlopen) into the process?

Same thing, except the linker is dynamic.

> What about threads which were started before that dynamic library was loaded, and therefore did not have enough space in their per-thread area for that thread-local variable, when they call into code which references it? What happens if the thread-local variable has an initializer?

Seriously? I mean, you probably do have enough space because address space is huge, but dlopen should move TLS.

> links to a 81-page document describing four TLS access models, and that's just for Unix-style ELF

Just because someone can write 81-pages about something doesn't mean that it takes 81-pages to understand something.