This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.
Differential Revision: https://reviews.llvm.org/D42214
llvm-svn: 323169
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
Summary:
This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers.
The changes in this patch are:
* remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers.
* Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles.
* Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang.
I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check?
This refactor is needed to support upcoming fixes to `<locale>` on Windows.
Reviewers: bcraig, rmaprath, compnerd, EricWF
Reviewed By: EricWF
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D32988
llvm-svn: 302727
The ERROR_TIMEDOUT returned by the Windows API does not
have the same value as ETIMEDOUT. This caused condition_variable
to return timeouts as unknown errors.
llvm-svn: 302297
This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should
be alertable, the implementation causes a large regression in the test
suite. Add a FIXME item there for now to get the test suite in a better
state before attempting to fix that behaviour.
llvm-svn: 295561
On Windows, we were using `Sleep` which is not alertable. This means
that if the thread was used for a user APC or WinProc handling and
thread::sleep was used, we could potentially dead lock. Use `SleepEx`
with an alertable sleep, resuming until the time has expired if we are
awoken early.
llvm-svn: 295329
Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.
Differential revision: https://reviews.llvm.org/D29630
Reviewers: EricWF, joerg
llvm-svn: 294573
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
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
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
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
We have already refactored the underlying platform thread type into
__libcpp_thread_t, but there are few places in the source where we
still assume it is an integral type.
This patch refactores those points back into the threading API.
Differential revision: https://reviews.llvm.org/D28608
Reviewers: EricWF
llvm-svn: 292107
Although the CriticalSection itself doesnt need to be destroyed, there
may be debug data associated with it. Plug a possible small leak.
llvm-svn: 291536
Add an implementation for the Win32 threading model as a backing API for
the internal c++ threading interfaces. This uses the Fls* family for
the TLS (which has the support for adding termination callbacks),
CRITICAL_SECTIONs for the recursive mutex, and Slim Reader/Writer locks
(SRW locks) for non-recursive mutexes. These APIs should all be
available on Vista or newer.
llvm-svn: 291333
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
Split out the recursive and non-recursive mutex. This split is needed
for platforms which may use differing types for the two mutex (e.g.
Win32 threads).
llvm-svn: 291145
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
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
This fixes a small omission where even when __external_threading is provided,
we attempt to declare a pthread based threading API. Instead, we should leave
out everything for the __external_threading header to take care of.
The __threading_support header provides a proof-of-concept externally threaded
libc++ variant when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined. But if the
__external_threading header is present, we should exclude all of that POC stuff.
Reviewers: EricWF
Differential revision: https://reviews.llvm.org/D25468
llvm-svn: 284232
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
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.
This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.
http://reviews.llvm.org/D20573
llvm-svn: 270735
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
Peter Collingbourne