diff options
| author | Howard Hinnant <hhinnant@apple.com> | 2011-05-19 15:05:04 +0000 |
|---|---|---|
| committer | Howard Hinnant <hhinnant@apple.com> | 2011-05-19 15:05:04 +0000 |
| commit | ec0810e1c8e690ebbf571670820392d52fb23b75 (patch) | |
| tree | d4646969f53e635646ead35706b54fad1aa256ca /libcxx/include/thread | |
| parent | b8f65e25d8e1a9e45bee589a9238cf6fe8363b88 (diff) | |
| download | bcm5719-llvm-ec0810e1c8e690ebbf571670820392d52fb23b75.tar.gz bcm5719-llvm-ec0810e1c8e690ebbf571670820392d52fb23b75.zip | |
I had a giant misunderstanding of what 'synchronizes with' meant in [futures.async]/p5. This invalidated the current design of async in <future>. This is a new design, based on my new understanding, which has been confirmed on the lwg mailing list. The summary is that ~future() (and ~shared_future()) will block when they are created from within async, and the thread hasn't finished yet. As part of this work I created two new type traits: __invokable<F, Args...>::value and __invoke_of<F, Args...>::type. These are what result_of<F(Args...)> wanted to be when it grew up, but never will be. __invoke_of is carefully crafted so that it can serve as its own enable_if (type doesn't exist if the signature isn't invokable). All of this work is C++11 only.
llvm-svn: 131639
Diffstat (limited to 'libcxx/include/thread')
| -rw-r--r-- | libcxx/include/thread | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libcxx/include/thread b/libcxx/include/thread index ca16d213829..a04572f6be2 100644 --- a/libcxx/include/thread +++ b/libcxx/include/thread @@ -325,7 +325,7 @@ inline _LIBCPP_INLINE_VISIBILITY void __threaad_execute(tuple<_F, _Args...>& __t, __tuple_indices<_Indices...>) { - _STD::move(_STD::get<0>(__t))(_STD::move(_STD::get<_Indices>(__t))...); + __invoke(_STD::move(_STD::get<0>(__t)), _STD::move(_STD::get<_Indices>(__t))...); } template <class _F> |
