[PATCH] D19412: [libcxx] Refactor pthread usage - II

[Eric Fiselier via cfe-commits]

EricWF added a comment.

In http://reviews.llvm.org/D19412#416596, @rmaprath wrote:

> In http://reviews.llvm.org/D19412#416183, @EricWF wrote:
>
> > OK. I *think* this is my last round of review comments except for one specific issue. I'm still looking into the changes to the static mutex's and condition_variables in `memory.cpp` and `algorithm.cpp`. In these cases I don't want to go from compile-time initialization to run-time initialization.  This could introduce the static initialization order fiasco.
>
>
> So, as pointed out earlier by @bcraig, there won't be a runtime overhead for those compilers supporting `constexr`. For those that don't, this is still a trivial enough constructor call that is very likely to get optimized away. To elaborate, we can simplify this scenario to something like:
>
> **thread.h**
>
>   struct thread_t {
>     int state1;
>     int *state2;
>     bool state3;
>   };
>  
>   #define THREAD_INITIALIZER  {0, 0, false}
>
>
> **test.cpp**
>
>   #include "thread.h"
>  
>   class Foo {
>   private:
>     thread_t __t_;
>   public:
>     Foo() {__t_ = (thread_t) THREAD_INITIALIZER;}
>   };
>


Foo has a trivial destructor. Our mutex does not. I've already looked into the codegen for clang and in each case your change creates runtime code. The constructors may still be optimized away but it still has to register the destructors.

I'm just trying to figure out if that's going to be a problem.

Example here: https://godbolt.org/g/dJL29v


http://reviews.llvm.org/D19412