tdauth / cpp-futures-promises Goto Github PK

Each link links to the previous callback.
This improves the performance of adding a new callback with onComplete.

See file "src/advanced/shared_future.cpp".

Add test cases for the Boost.Thread implementation.

Use ctx->v.emplace_back(i, std::move(t)); instead.

The default should be shared futures and promises.
For performance optimization, we could also provide futures and promises which can only be moved.
How do we implement derived features for such futures and promises?

Add methods share to allow a conversion.

See https://www.quora.com/Is-there-any-gorgeous-way-for-C++-to-return-an-object-without-copying-it-in-memory

Both tests fail when we get the exception from a resulting Try.

Deleting the final promise reference to a core instance should try to complete it with BrokenPromise. This prevents starvations of programs and firstSucc automatically.

Add a separate project for comparisons with Boost and Folly.
This project should only contain the Advanced Futures and Promises.
We can drop the dependency to Folly after the splitting.

Provide an abstract class for executors which does not depend on Folly.

There is a data race bug in the firstN and firstNSucc implementations. Make sure that the vector element is added BEFORE the promise is completed. Therefore, do not check if c == n but if the vector's size == n!

According to http://www.cplusplus.com/reference/vector/vector/size/ accessing the vector's size is thread-safe and does not lead to data races.
However, to be absolutely sure that the size has the correct value, we can still use the atomic size counter which is increased, after the element is added.

See our short paper: https://www.researchgate.net/publication/330066278_Futures_and_promises_in_Haskell_and_Scala
And the Scala reference implementation: https://github.com/tdauth/PEPM19-supplementary-material-scala

We could add the same benchmarks as well to compare the three implementations.

See https://github.com/STEllAR-GROUP/hpx

It provides futures and promises and more useful combinators when_any than Boost.

See http://stellar-group.org/2015/07/hpx-and-cpp-futures/
See http://stellar-group.org/2015/05/hpx-and-cpp-executors/

We should add HPX to the benchmark to compare the performance.

We need a factory which creates a new Core instance based on the type of a previous instance.
This allows support for different types.

The type is important for the constructor of the type adv::Promise.

At the moment the methodCore<T>::createShared(folly::Executor *executor); creates the instances.

See:

• https://blog.kitware.com/cmake-ctest-and-cdash-at-netflix/
• https://www.cdash.org/

How to integrate it with TravisCI?

• Test all combinators like the Folly ones in the performance tree test.
• Complete all TODOs.
• Add a shared future based on Boost.Thread's boost::shared_future only if it makes sense. Does it already allow registering multiple callbacks?

Find all TODOs and solve them.

There is a destructor call of a promise with an empty state in Future<T>::then<S>() when using onComplete.
Actually, there should be only one destructor call of a promise (the copy) and not two.
Where does the promise with the empty state come from?
How is it possible to create a promise with an empty state?

Memory error can be reproduced:

auto p = createPromiseInt();
p.trySuccess(10);
auto f = p.future();
auto tmp = createPromiseInt();
f.onComplete([tmp](const Try<int> &t) {});

Without capturing tmp, everything works fine.

The fix is actually very simple: Remove move constructors and assignment operators from Promise and Future. Otherwise, the shared pointer of Promise can become invalid. We do not need to move these types. They are designed to be copied.

Since September 2017, the executors of Wangle have been moved to Folly, so there is no need for Wangle anymore: https://github.com/facebook/folly/commits/ac6b1e283b5f09a39f17a2c8014275135c808bfb/folly/executors/ThreadPoolExecutor.h

• Drop the dependency to Wangle and update to the latest versions of Boost and Folly.
• The latest version of Folly supports a CMake build rather than an automake build: https://github.com/facebook/folly/blob/master/README.md Still trying to figure out if it actually works on Fedora: facebook/folly#923

Since Folly can be used as CMake package now and it is supported by CMake Hunter (https://github.com/ruslo/hunter/issues/838) maybe change to hunter to simplify the whole build process. Of course, we cannot use the latest releases/git versions of the repository then.

This will detect dead lock errors more easily.

It blocks and if there are no threads left in the executor, it will lead to a deadlock.
Just implement it like Scala FP with transform and transformWith.

tryCompleteWith registers a callback on the passed future with a reference to the current promise but what happens if the promise is released before the future is completed?
The destructor of the promise has to keep track of these calls and notify them.

At the moment there is many warnings.
Install the correct files?

It seems that the three test cases which fail most of the time for unique futures are:

• unknown location(0): fatal error: in "FirstWithExceptionBoost": unknown type src/advanced/future.cpp(232): last checkpoint
• unknown location(0): fatal error: in "TryFailureBoost": unknown type
  src/advanced/future.cpp(407): last checkpoint
• unknown location(0): fatal error: in "TryFailureWithBoost": unknown type
  src/advanced/future.cpp(483): last checkpoint: "TryFailureWithBoost" test entry

Probably, the expected std::runtime_error is not rethrown which would be caught when catching the type std::exception. Maybe it has something to do with the storage of std::exception_ptr in the class Try.
adv_boost::Try::get() should rethrow the actual exception which has been stored under the std::exception_ptr object!
Look at folly:Try. It uses folly::exception_wrapper to store the exception.

Asked on StackOverflow: https://stackoverflow.com/questions/52043506/how-to-rethrow-the-original-exception-stored-by-an-stdexception-ptr-with-a-boo

Don't pull a complete Fedora image. Just use the CMake repo and all libs.