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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
