[Spec] {.threadvar.} and destructors

[mratsim]

As discussed on IRC (https://irclogs.nim-lang.org/07-11-2019.html#18:25:52), the spec doesn't cover if destructors are inserted for thread-local variable before thread destruction.

It should say clearly if they are or if they are not.

[Araq]

They are not injected but the real question is whether that's really good enough... Likewise, collecting all threadlocal destructors into a single one is not modular and requires a heavier threading implementation than I would like.

We probably need to do the same as: https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables

[timotheecour]

the spec doesn't cover if destructors are inserted for thread-local variable before thread destruction.

IMO we should ensure that destructors are inserted, even if this only holds for C++, and even if that only holds furthermore for >= C++11 (until we implement this for C backend as well or tlsEmulation:off). That's the most sensible behavior for correctnesss / usefulness.

note that now that #16750 was merged, for {.cppNonPod.} importcpp types that have a destructor, a TLS variable (which is now mapped to a C++11 thread_local) will have its C++ destructor called on thread termination; a test still needs to be added to ensure this but this is what I had observed when writing #16750

question

@Araq are nim destructors mapped to a C++ destructor on C++ backend? and does it depend on --gc:arc|default?

if so, then looks like this provides a full solution for C++11 (and we must also ensure that nim destructor for a type Foo has same behavior as {.cppNonPod.}, ie makes a TLS use thread_local even if that type wasn't even importcpp.