[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281179 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/include/thread b/include/thread
index 21cc761..7fe4c77 100644
--- a/include/thread
+++ b/include/thread
@@ -137,7 +137,7 @@
template <class _Tp>
class __thread_specific_ptr
{
- __libcpp_tl_key __key_;
+ __libcpp_tls_key __key_;
// Only __thread_local_data() may construct a __thread_specific_ptr
// and only with _Tp == __thread_struct.
@@ -155,7 +155,7 @@
~__thread_specific_ptr();
_LIBCPP_INLINE_VISIBILITY
- pointer get() const {return static_cast<_Tp*>(__libcpp_tl_get(__key_));}
+ pointer get() const {return static_cast<_Tp*>(__libcpp_tls_get(__key_));}
_LIBCPP_INLINE_VISIBILITY
pointer operator*() const {return *get();}
_LIBCPP_INLINE_VISIBILITY
@@ -173,7 +173,7 @@
template <class _Tp>
__thread_specific_ptr<_Tp>::__thread_specific_ptr()
{
- int __ec = __libcpp_tl_create(
+ int __ec = __libcpp_tls_create(
&__key_,
&__thread_specific_ptr::__at_thread_exit);
if (__ec)
@@ -196,7 +196,7 @@
{
_LIBCPP_ASSERT(get() == nullptr,
"Attempting to overwrite thread local data");
- __libcpp_tl_set(__key_, __p);
+ __libcpp_tls_set(__key_, __p);
}
class _LIBCPP_TYPE_VIS thread;