summaryrefslogtreecommitdiff
path: root/libcxx/docs/DesignDocs/ThreadingSupportAPI.rst
AgeCommit message (Collapse)Author
2024-11-06[libc++] Refactor the configuration macros to being always defined (#112094)Nikolas Klauser
This is a follow-up to #89178. This updates the `<__config_site>` macros.
2024-01-30[libc++] Split the monolithic __threading_support header (#79654)Louis Dionne
The <__threading_support> header is a huge beast and it's really difficult to navigate. I find myself struggling to find what I want every time I have to open it, and I've been considering splitting it up for years for that reason. This patch aims not to contain any functional change. The various implementations of the threading base are simply moved to separate headers and then the individual headers are simplified in mechanical ways. For example, we used to have redundant declarations of all the functions at the top of `__threading_support`, and those are removed since they are not needed anymore. The various #ifdefs are also simplified and removed when they become unnecessary. Finally, this patch adds documentation for the API we expect from any threading implementation.
2023-07-17[libc++] Remove internal "build-with-external-thread-library" configurationLouis Dionne
Our threading support layer is currently a huge mess. There are too many configurations with too many confusing names, and none of them are tested in the usual CI. Here's a list of names related to these configurations: LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL This patch cleans this up by removing the ability to build libc++ with an "external" threading library for testing purposes, removing 4 out of 6 "names" above. That setting was meant to be used by libc++ developers, but we don't use it in-tree and it's not part of our CI. I know the ability to use an external threading API is used by some folks out-of-tree, and this patch doesn't change that. This only changes the way they will have to test their external threading support. After this patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON` when building the library, and to provide their usual `<__external_threading>` header when they are testing the library. This can be done easily now that we support custom lit configuration files in test suites. The motivation for this patch is that our threading support layer is basically unmaintainable -- anything beyond adding a new "backend" in the slot designed for it requires incredible attention. The complexity added by this setting just doesn't pull its weigh considering the available alternatives. Concretely, this will also allow future patches to clean up `<__threading_support>` significantly. Differential Revision: https://reviews.llvm.org/D154466
2018-01-05[cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 ↵Martin Storsjo
threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
2017-01-16[libcxx] Improve design documentation for the external-thread-libraryAsiri Rathnayake
configuration NFC. Differential revision: https://reviews.llvm.org/D28610 Reviewers: EricWF llvm-svn: 292108
2017-01-06[libc++] Cleanup and document <__threading_support>Eric Fiselier
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