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

Reply via email to