fix #16752: threadvar now works with importcpp types; osx now uses native TLS (--tlsEmulation:off), which can be orders of magnitude faster

[timotheecour]

• fix threadvar doesn't work for importcpp types #16752: threadvar works with cpp types, with --tlsEmulation:off (ie native TLS)
• osx now uses native TLS
• see benchmark (yes, they're intended to be part of this PR, I intend to grow tests/benchmarks/ in the future, see add performance regression tests that can be tracked over git commit history timotheecour/Nim#425)
• a new pragma {.cppNonPod.} specifies a importcpp type is a non-POD, and shall use thread_local instead of __thread for {.threadvar.} variables

links

• see https://stackoverflow.com/questions/28094794/why-does-apple-clang-disallow-c11-thread-local-when-official-clang-supports but native TLS support predates this

The clang compiler included with Xcode 8 and later supports the C++11 thread_local keyword.

Regarding iOS, I found by experimentation that thread_local is supported for iOS 9 and later, but not for iOS 8.4 or earlier.

• https://en.wikipedia.org/wiki/Thread-local_storage#C.2B.2B

• __thread vs thread_local: https://stackoverflow.com/questions/12049095/c11-nontrivial-thread-local-static-variable

thread_local and __thread are, in fact, not the same thing. The main difference between them is precisely the one you stumbled upon - thread_local allows the variable to be non-POD.

AFAIK nim uses POD types in cgen code, even for types with destructors, and even for c++

• https://stackoverflow.com/questions/13106049/what-is-the-performance-penalty-of-c11-thread-local-variables-in-gcc-4-8

freebsd, openbsd, netbsd

I didn't change the behavior here, but see: #15066 (comment) and #15493

note regarding cppNonPod

I used pod for simplicity in the pragma name even though __is_pod trait will be deprecated (see https://stackoverflow.com/a/48225882/1426932):

__is_pod (C++, GNU, Microsoft, Embarcadero): Note, the corresponding standard trait was deprecated in C++20.

this pragma is user defined anyways, and the compiler will error if that pragma is missing, resulting in __thread being used on a variable of a type that contains non-trivial destructor or if type has a constructor and cgen calls var a: Foo.

So in the end it works as intended.

note regarding thread_local

• if needed, in future work, we can use __has_feature(cxx_thread_local) conditionally
• C++11 thread_local is supported on OSX since xcode 8, released in 2016
• ios supports thread_local since ios9 refs https://stackoverflow.com/a/29929949/1426932

future work

• there are other use cases for {.cppNonPod.}, eg thread safe static initialization:
  instead of Error: a thread var cannot be initialized explicitly; this would only run for the main thread we could allow:

when true:
  proc main =
    var g0 {.threadvar.} = 12
  main()

• see how to fix the disabled part of ttlsemulation.nim that fails for windows with cpp --threads --tlsEmulation:off

• address this: fix #16752: threadvar now works with importcpp types; osx now uses native TLS (--tlsEmulation:off), which can be orders of magnitude faster #16750 (comment)

move all ffi pragmas (including nodecl, incompleteStruct etc) into lib/ffi.rst;

[mratsim]

Linked to #12624 [Spec] {.threadvar.} and destructors

Also linked to Weave issue mratsim/weave#61 (comment)

Note that on Mac, tlsEmulation was on by default for iPhone support which lagged a bit behind MacOSX.

[mratsim]

Another issue with tlsEmulation on Windows, Ctrl-C will crash your program #4057.

[ringabout]

LGTM

[timotheecour]

ping @Araq

[Araq]

Instead of yet another pragma, we should IMHO mark non-pod C++ types with an importc'ed destructor or similar.

[timotheecour]

{.cppNonPod.} is much simpler, both for end users code and nim compiler code.

importc'ed destructor

that won't work, Foo2 below has a default destructor but can't be used with __thread (otherwise gives: error: initializer for thread-local variable must be a constant expression)

struct Foo2 {
  Foo2() { }
};
int main() {
  static __thread Foo2 a2;
  return 0;
}

or similar

I don't see how this can work either.
If Derived is a subclass of some Base which has a non-default constructor (eg: case 2, case 3 below), you also can't use __thread.

# case 1: works
struct Base {
};

# case 2: doesn't work
struct Base {
  Base() { }
};

# case 3: doesn't work
struct Base {
  Base(int n) { }
};

# case 4: works
struct Base {
  Base() = default;
  Base(int n) { } # with or without this
};

# rest of code:
struct Derived : public Base {
};

void bar() {
  static __thread Derived a2;
}

int main (int argc, char *argv[]) {
  bar();
  return 0;
}

As you can see the determination of whether to use __thread or thread_local is complex and can't be made on sole basis of looking for non-trivial destructors or constructors, you'd have to also look at all base classes, this is impractical because a nim user may not wish to declare all (recursive) bases classes of the class they're interested in wrapping, nor their constructors/destructors; and nim shouldn't re-implement the complex logic already done in C++ compiler.

[Araq]

Ok, I'm convinced. But can we move the FFI pragmas out of the manual to an "appendix"? These things shouldn't be part of the language "spec".

[timotheecour]

But can we move the FFI pragmas out of the manual to an "appendix"

I'm happy to do that in a followup PR, which would move all ffi pragmas (including nodecl, incompleteStruct etc) into lib/ffi.rst; this is out of scope for this PR though.