summaryrefslogtreecommitdiffstats
path: root/libcxx/test/support/external_threads.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Cleanup and document <__threading_support>Eric Fiselier2017-01-061-1/+1
| | | | | | | | | | | | | | | Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
* [libcxx] Fix testing of the externally-threaded library buildAsiri Rathnayake2017-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | after r290850 Before r290850, building libcxx with -DLIBCXX_HAS_EXTERNAL_THREAD_API=ON had two uses: - Allow platform vendors to plug-in an __external_threading header which should take care of the entire threading infrastructure of libcxx - Allow testing of an externally-threaded library build; where the thread API is declared using pthread data structures, and the implementation of this API is provided as a separate library (test/support/external_threads.cpp) and linked-in when running the test suite. r290850 breaks the second use case (pthread data structures are no longer available). This patch re-stores the ability to build+test an externally-threaded library variant on a pthread based system. llvm-svn: 290878
* threading_support: refactor for Win32 threadingSaleem Abdulrasool2017-01-031-1/+1
| | | | | | | | | Refactor the header to allow us to implement alternate threading models with alternate data structures. Take the opportunity to clang-format the area. This will allow us to avoid re-declaring the interfaces for Win32 threading. NFC llvm-svn: 290850
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-0/+10
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
OpenPOWER on IntegriCloud