summaryrefslogtreecommitdiffstats
path: root/libcxx/src/condition_variable.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx{,abi}] Emit deplibs only when detected by CMakeMichał Górny2019-12-021-1/+1
| | | | | | | | This is a followup to 35bc5276ca3. It fixes the dependent libs usage in libcxx and libcxxabi to link pthread and rt libraries only if CMake detects them, rather than based on explicit platform blacklist. Differential Revision: https://reviews.llvm.org/D70888
* [runtimes] Don't depend on libpthread on AndroidYi Kong2019-07-221-1/+1
| | | | | | | | | | r362048 added support for ELF dependent libraries, but broke Android build since Android does not have libpthread. Remove the dependency on the Android build. Differential Revision: https://reviews.llvm.org/D65098 llvm-svn: 366734
* Make ~mutex and ~condition_variable trivial on Windows.Eric Fiselier2019-07-071-4/+1
| | | | | | | | | The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy are already NOPs, so this optimization is safe to perform. See r365273 and PR27658 for more information. llvm-svn: 365281
* [libc++] Avoid using timespec when it might not be availableMikhail Maltsev2019-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The type timespec is unconditionally used in __threading_support. Since the C library is only required to provide it in C11, this might cause problems for platforms with external thread porting layer (i.e. when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11 C libraries. In our downstream port of libc++ we used to provide a definition of timespec in __external_threading, but this solution is not ideal because timespec is not a reserved name. This patch renames timespec into __libcpp_timespec_t in the thread-related parts of libc++. For all cases except external threading this type is an alias for ::timespec (and no functional changes are intended). In case of external threading it is expected that the __external_threading header will either provide a similar typedef (if timespec is available in the vendor's C library) or provide a definition of __libcpp_timespec_t compatible with POSIX timespec. Reviewers: ldionne, mclow.lists, EricWF Reviewed By: ldionne Subscribers: dexonsmith, libcxx-commits, christof, carwil Tags: #libc Differential Revision: https://reviews.llvm.org/D63328 llvm-svn: 364012
* [runtimes] Use _LIBCPP_HAS_COMMENT_LIB_PRAGMA in all relevant filesPetr Hosek2019-05-301-1/+1
| | | | | | These two sources were omitted in r362055. llvm-svn: 362061
* [runtimes] Support ELF dependent libraries featurePetr Hosek2019-05-301-0/+4
| | | | | | | | | | | | | | | | | | | As of r360984, LLD supports dependent libraries feature for ELF. libunwind, libc++abi and libc++ have library dependencies: libdl librt and libpthread, which means that when libunwind and libc++ are being statically linked (using -static-libstdc++ flag), user has to manually specify -ldl -lpthread which is onerous. This change includes the lib pragma to specify the library dependencies directly in the source that uses those libraries. This doesn't make any difference when using linkers that don't support dependent libraries. However, when using LLD that has dependent libraries feature, users no longer have to manually specifying library dependencies when using static linking, linker will pick the library automatically. Differential Revision: https://reviews.llvm.org/D62090 llvm-svn: 362048
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | | to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351648
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-0/+1
| | | | | | | | | | | | | | | | Summary: This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning. This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header. Reviewers: mclow.lists, bcraig, compnerd, EricWF Reviewed By: EricWF Subscribers: cfe-commits, krytarowski Differential Revision: https://reviews.llvm.org/D33080 llvm-svn: 304357
* Recommit [libcxx] Never use <cassert> within libc++Eric Fiselier2017-02-041-1/+0
| | | | | | | | | | It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. llvm-svn: 294107
* Revert "[libcxx] Never use <cassert> within libc++"Eric Fiselier2017-01-241-0/+1
| | | | | | | | This reverts commit r292883. Unfortunately <string_view> uses _LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib build. I'll investigate more tomorrow. llvm-svn: 292923
* [libcxx] Never use <cassert> within libc++Eric Fiselier2017-01-241-1/+0
| | | | | | | | | | | | | | | | | Summary: It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead. Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to. Reviewers: mclow.lists, compnerd, smeenai Reviewed By: mclow.lists Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D29063 llvm-svn: 292883
* Fix PR30202 - notify_all_at_thread_exit seg faults if run from a raw pthread ↵Eric Fiselier2016-09-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context. Summary: This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`. Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec: > > Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread. > > An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits. > > If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop. However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit". Reviewers: mclow.lists, bcraig, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24159 llvm-svn: 280588
* Refactor pthread usage of libcxx.Asiri Rathnayake2016-05-061-5/+5
| | | | | | | | | | | | | This patch extracts out all the pthread dependencies of libcxx into the new header __threading_support. The motivation is to make it easy to re-target libcxx into platforms that do not support pthread. Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781 Applied with tweaks - D19412 Change-Id: I301111f0075de93dd8129416e06babc195aa936b llvm-svn: 268734
* Allow libc++ to be built on systems without POSIX threadsJonathan Roelofs2014-09-051-0/+6
| | | | | | | | | | If you're crazy enough to want this sort of thing, then add -D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and --param=additiona_features=libcpp-has-no-threads to your lit commnad line. http://reviews.llvm.org/D3969 llvm-svn: 217271
* Implement LWG issue #2135. If something goes wrong in ↵Marshall Clow2014-03-261-2/+2
| | | | | | condition_variable::wait, call terminate() rather than throwing an error. Do this indirectly, by marking the call as 'noexcept'. This is better than just calling terminate() directly, because it gives a better error message on the console. llvm-svn: 204778
* Change sleep_for, sleep_until, and the condition_variable timed waitHoward Hinnant2012-08-301-2/+14
| | | | | | | | | | | | | functions to protect against duration and time_point overflow. Since we're about to wait anyway, we can afford to spend a few more cycles on this checking. I purposefully did not treat the timed try_locks with overflow checking. This fixes http://llvm.org/bugs/show_bug.cgi?id=13721 . I'm unsure if the standard needs clarification in this area, or if this is simply QOI. The <chrono> facilities were never intended to overflow check, but just to not overflow if durations stayed within +/- 292 years. llvm-svn: 162925
* noexcept applied to <condition_variable>.Howard Hinnant2012-07-211-2/+2
| | | | llvm-svn: 160605
* Quash a whole bunch of warningsHoward Hinnant2011-12-011-2/+1
| | | | llvm-svn: 145624
* license changeHoward Hinnant2010-11-161-2/+2
| | | | llvm-svn: 119395
* Convert __thread_local_data to the singleton patternHoward Hinnant2010-10-141-1/+1
| | | | llvm-svn: 116500
* [futures.atomic_future] and notify_all_at_thread_exit. This completes the ↵Howard Hinnant2010-09-031-0/+6
| | | | | | header <future> and all of Chapter 30 (for C++0x enabled compilers). llvm-svn: 113017
* Wiped out some non-ascii characters that snuck into the copyright.Howard Hinnant2010-05-111-1/+1
| | | | llvm-svn: 103516
* libcxx initial importHoward Hinnant2010-05-111-0/+64
llvm-svn: 103490
OpenPOWER on IntegriCloud