[PATCH] D11781: Refactored pthread usage in libcxx

[David Chisnall via cfe-commits]

theraven added inline comments.

================
Comment at: include/__mutex_base:246
@@ -266,3 +245,3 @@
 
-class _LIBCPP_TYPE_VIS condition_variable
+class _LIBCPP_TYPE_VIS condition_variable : private __libcxx_support::condition_variable
 {
----------------
espositofulvio wrote:
> theraven wrote:
> > espositofulvio wrote:
> > > theraven wrote:
> > > > Does this change the ABI for a mutex on *NIX platforms?  We can't change the class layout for existing platforms (though we can indirect things via typedefs).
> > > My hunch is that it doesn't, std::condition_variable has no data member now and the first base class (__libcxx_support::condition_variable) contains only pthread_cond_t which will be effectively laid out at the starting address of the object,  as it was previously for std::condition_variable,. I will check this out later in the evening though.
> > I *think* that it's correct, but it's worth compiling a program that has one compilation unit using the old header and another using the new one and check that it's able to interoperate correctly.
> > 
> > Also check whether this depends on the implementation of the condition variable.  On FreeBSD, the pthread types are all pointers (currently - we're going to have some painful ABI breakage at some point when we move them to being something that can live in shared memory).  In glibc, they're structures.  I don't think that you'll end up with different padding in the ABI from wrapping them in a class, but it's worth checking.
> > it's worth compiling a program that has one compilation unit using the old header and another using the new one and check that it's able to interoperate correctly
> 
> Unfortunately this isn't going to work, some simbols are now defined in __libcxx_support and not in std (they are just made available through using), so an object file that includes the old header won't link against the new library (unreferenced symbols). The alternative is to create inline forwarding methods.
> 
> 
> 
That's going to need some more refactoring then.  Breaking the public ABI of libc++ would be a show-stopper.


Repository:
  rL LLVM

http://reviews.llvm.org/D11781