2016-05-06 22:06:29 +08:00
|
|
|
// -*- C++ -*-
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is dual licensed under the MIT and the University of Illinois Open
|
|
|
|
// Source Licenses. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_THREADING_SUPPORT
|
|
|
|
#define _LIBCPP_THREADING_SUPPORT
|
|
|
|
|
|
|
|
#include <__config>
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
|
|
|
|
#pragma GCC system_header
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef _LIBCPP_HAS_NO_THREADS
|
|
|
|
|
2016-10-14 21:56:58 +08:00
|
|
|
#ifndef __libcpp_has_include
|
|
|
|
#ifndef __has_include
|
|
|
|
#define __libcpp_has_include(x) 0
|
|
|
|
#else
|
|
|
|
#define __libcpp_has_include(x) __has_include(x)
|
|
|
|
#endif
|
2016-09-13 17:32:32 +08:00
|
|
|
#endif
|
|
|
|
|
2017-01-03 19:32:31 +08:00
|
|
|
#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
|
|
|
|
// as a separate library.
|
|
|
|
#define _LIBCPP_HAS_THREAD_API_EXTERNAL_PTHREAD
|
|
|
|
#endif
|
|
|
|
|
2016-10-14 21:56:58 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_EXTERNAL) && \
|
|
|
|
__libcpp_has_include(<__external_threading>)
|
|
|
|
#include <__external_threading>
|
|
|
|
#else
|
2017-01-03 10:00:31 +08:00
|
|
|
|
2017-01-03 19:32:31 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) || \
|
|
|
|
defined(_LIBCPP_HAS_THREAD_API_EXTERNAL_PTHREAD)
|
2016-05-06 22:06:29 +08:00
|
|
|
#include <pthread.h>
|
|
|
|
#include <sched.h>
|
2017-01-03 10:00:31 +08:00
|
|
|
#endif
|
2016-05-06 22:06:29 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
|
|
|
|
#define _LIBCPP_THREAD_ABI_VISIBILITY _LIBCPP_FUNC_VIS
|
|
|
|
#else
|
|
|
|
#define _LIBCPP_THREAD_ABI_VISIBILITY inline _LIBCPP_INLINE_VISIBILITY
|
|
|
|
#endif
|
2016-05-06 22:06:29 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_BEGIN_NAMESPACE_STD
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2017-01-03 19:32:31 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) || \
|
|
|
|
defined(_LIBCPP_HAS_THREAD_API_EXTERNAL_PTHREAD)
|
2016-05-06 22:06:29 +08:00
|
|
|
// Mutex
|
|
|
|
typedef pthread_mutex_t __libcpp_mutex_t;
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
#define _LIBCPP_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
// Condition Variable
|
|
|
|
typedef pthread_cond_t __libcpp_condvar_t;
|
|
|
|
#define _LIBCPP_CONDVAR_INITIALIZER PTHREAD_COND_INITIALIZER
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
typedef pthread_once_t __libcpp_exec_once_flag;
|
|
|
|
#define _LIBCPP_EXEC_ONCE_INITIALIZER PTHREAD_ONCE_INIT
|
|
|
|
|
|
|
|
// Thread id
|
2017-01-03 10:00:31 +08:00
|
|
|
typedef pthread_t __libcpp_thread_id;
|
|
|
|
|
|
|
|
// Thread
|
|
|
|
typedef pthread_t __libcpp_thread_t;
|
|
|
|
|
|
|
|
// Thrad Local Storage
|
|
|
|
typedef pthread_key_t __libcpp_tls_key;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
// Mutex
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_recursive_mutex_init(__libcpp_mutex_t *__m);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_lock(__libcpp_mutex_t *__m);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_trylock(__libcpp_mutex_t *__m);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_unlock(__libcpp_mutex_t *__m);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_destroy(__libcpp_mutex_t *__m);
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
|
|
|
|
// Condition variable
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_signal(__libcpp_condvar_t* __cv);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_broadcast(__libcpp_condvar_t* __cv);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_wait(__libcpp_condvar_t* __cv, __libcpp_mutex_t* __m);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
|
|
|
|
timespec *__ts);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_condvar_destroy(__libcpp_condvar_t* __cv);
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
int __libcpp_execute_once(__libcpp_exec_once_flag *flag,
|
|
|
|
void (*init_routine)(void));
|
|
|
|
|
|
|
|
// Thread id
|
|
|
|
#if defined(__APPLE__) && !defined(__arm__)
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
mach_port_t __libcpp_thread_get_port();
|
|
|
|
#endif
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2);
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2);
|
|
|
|
|
|
|
|
// Thread
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
|
|
|
|
void *__arg);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_current_id();
|
2017-01-03 10:00:31 +08:00
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t *__t);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_join(__libcpp_thread_t *__t);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_detach(__libcpp_thread_t *__t);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
|
|
|
void __libcpp_thread_yield();
|
|
|
|
|
|
|
|
// Thread local storage
|
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_tls_create(__libcpp_tls_key *__key, void (*__at_exit)(void *));
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 10:00:31 +08:00
|
|
|
void *__libcpp_tls_get(__libcpp_tls_key __key);
|
|
|
|
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
_LIBCPP_THREAD_ABI_VISIBILITY
|
2017-01-03 20:59:50 +08:00
|
|
|
int __libcpp_tls_set(__libcpp_tls_key __key, void *__p);
|
[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
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
|
2017-01-03 19:32:31 +08:00
|
|
|
#if defined(_LIBCPP_HAS_THREAD_API_PTHREAD) || \
|
|
|
|
defined(_LIBCPP_BUILDING_THREAD_API_EXTERNAL_PTHREAD)
|
2016-05-06 22:06:29 +08:00
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_recursive_mutex_init(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
pthread_mutexattr_t attr;
|
|
|
|
int __ec = pthread_mutexattr_init(&attr);
|
|
|
|
if (__ec)
|
|
|
|
return __ec;
|
|
|
|
__ec = pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
__ec = pthread_mutex_init(__m, &attr);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutexattr_destroy(&attr);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
__ec = pthread_mutexattr_destroy(&attr);
|
|
|
|
if (__ec) {
|
|
|
|
pthread_mutex_destroy(__m);
|
|
|
|
return __ec;
|
|
|
|
}
|
|
|
|
return 0;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_lock(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_trylock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_trylock(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_unlock(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_mutex_destroy(__m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
// Condition Variable
|
|
|
|
int __libcpp_condvar_signal(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_signal(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_broadcast(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_broadcast(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_wait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_wait(__cv, __m);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_timedwait(__libcpp_condvar_t *__cv, __libcpp_mutex_t *__m,
|
|
|
|
timespec *__ts)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_timedwait(__cv, __m, __ts);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_condvar_destroy(__libcpp_condvar_t *__cv)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_cond_destroy(__cv);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
// Execute once
|
|
|
|
int __libcpp_execute_once(__libcpp_exec_once_flag *flag,
|
|
|
|
void (*init_routine)(void)) {
|
|
|
|
return pthread_once(flag, init_routine);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread id
|
|
|
|
#if defined(__APPLE__) && !defined(__arm__)
|
|
|
|
mach_port_t __libcpp_thread_get_port() {
|
|
|
|
return pthread_mach_thread_np(pthread_self());
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2016-05-06 22:06:29 +08:00
|
|
|
// Returns non-zero if the thread ids are equal, otherwise 0
|
|
|
|
bool __libcpp_thread_id_equal(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_equal(t1, t2) != 0;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Returns non-zero if t1 < t2, otherwise 0
|
|
|
|
bool __libcpp_thread_id_less(__libcpp_thread_id t1, __libcpp_thread_id t2)
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return t1 < t2;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Thread
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
|
|
|
|
void *__arg)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_create(__t, 0, __func, __arg);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
__libcpp_thread_id __libcpp_thread_get_current_id()
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_self();
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
__libcpp_thread_id __libcpp_thread_get_id(const __libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return *__t;
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_join(__libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_join(*__t, 0);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_thread_detach(__libcpp_thread_t *__t)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_detach(*__t);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void __libcpp_thread_yield()
|
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
sched_yield();
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Thread local storage
|
2017-01-03 10:00:31 +08:00
|
|
|
int __libcpp_tls_create(__libcpp_tls_key *__key, void (*__at_exit)(void *))
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_key_create(__key, __at_exit);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
void *__libcpp_tls_get(__libcpp_tls_key __key)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 10:00:31 +08:00
|
|
|
return pthread_getspecific(__key);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
int __libcpp_tls_set(__libcpp_tls_key __key, void *__p)
|
2016-05-06 22:06:29 +08:00
|
|
|
{
|
2017-01-03 20:59:50 +08:00
|
|
|
return pthread_setspecific(__key, __p);
|
2016-05-06 22:06:29 +08:00
|
|
|
}
|
|
|
|
|
2017-01-03 10:00:31 +08:00
|
|
|
#endif // _LIBCPP_HAS_THREAD_API_PTHREAD
|
2016-05-06 22:06:29 +08:00
|
|
|
|
|
|
|
_LIBCPP_END_NAMESPACE_STD
|
|
|
|
|
2016-10-14 21:56:58 +08:00
|
|
|
#endif // !_LIBCPP_HAS_THREAD_API_EXTERNAL || !__libcpp_has_include(<__external_threading>)
|
2016-10-14 21:00:07 +08:00
|
|
|
|
2016-05-06 22:06:29 +08:00
|
|
|
#endif // _LIBCPP_HAS_NO_THREADS
|
|
|
|
|
|
|
|
#endif // _LIBCPP_THREADING_SUPPORT
|