[PATCH] D20328: [libcxx] Externally threaded libc++ variant

[Ben Craig via cfe-commits]

bcraig added inline comments.

================
Comment at: include/__threading_support:201
@@ +200,3 @@
+// Mutex
+#define _LIBCPP_MUTEX_INITIALIZER nullptr
+struct __libcpp_platform_mutex_t;
----------------
rmaprath wrote:
> bcraig wrote:
> > I'm not sure I like taking the freedom to define _LIBCPP_MUTEX_INITIALIZER away from implementers.
> > 
> > Would it be too terrible to replace this entire #elif block with something like the following?
> > 
> > ```
> > #if !defined(__has_include) || __has_include(<os_provided_thread.h>)
> > #include <os_provided_thread.h>
> > #else
> > #error "_LIBCPP_THREAD_API_EXTERNAL requires the implementer to provide <os_provided_thread.h> in the include path"
> > #endif
> > ```
> > 
> > 
> The problem is that, `std::mutex` constructor needs to be `constexpr` (as you pointed out earlier). And since `__libcpp_mutex_t` is a pointer type (for this externally threaded variant), sensible definitions for `_LIBCPP_MUTEX_INITIALIZER` are limited.
> 
> Other than `nullptr`, one may be able to define `_LIBCPP_MUTEX_INITIALIZER` to be a pointer to some constant mutex (presuming that make it `constexpr` OK?) but I'm not convinced if such a setup would be very useful.
> 
> Hope that sounds sensible?
If the implementer gets to provide an entire header, then they also get to choose what libcpp_mutex_t will be.  They could make it a struct.


http://reviews.llvm.org/D20328