compnerd added a comment. I dont think that making Win32 threading an external one makes much sense unless we also do the same for pthreads. Its just as valid a threading model as pthreads, so why give preferential treatment to that? (Sure, there are more buildbots using it, but thats not a strong technical justification).
================ Comment at: include/__threading_support:30-50 #if defined(_LIBCPP_HAS_THREAD_API_EXTERNAL) && \ + !__libcpp_has_include(<__external_threading>) +// If the <__external_threading> header is absent, build libc++ against a +// pthread-oriented thread api but leave out its implementation. This setup +// allows building+testing of an externally-threaded library variant (on any +// platform that supports pthreads). Here, an 'externally-threaded' library +// variant is one where the implementation of the libc++ thread api is provided ---------------- Can you break this down into this which IMO is far more readable: #if defined(_LIBCPP_HAS_THREAD_API_EXTERNAL) #if __libcpp_has_include(<external_threading>) #include <__external_threading> #else // Why pthread? #define _LIBCPP_HAS_THREAD_API_EXTERNAL_PTHREAD #endif #endif #if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) || defined(_LIBCPP_HAS_THREAD_API_EXTERNAL_PTHREAD) #include <pthread.h> #include <sched.h> #endif https://reviews.llvm.org/D28229 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits