Boost :: Future Pending Deadlock Continuation

Question

I use Boosts promise and future and have come across an edge case when using continuations. My code uses a continuation that returns the future, and decompresses the result of then() s before its value.

 #define BOOST_THREAD_VERSION 5 #include <iostream> #include <boost/thread/future.hpp> int main(int argc, char* argv[]) { boost::promise<int> promise; boost::future<int> future = promise.get_future(); promise.set_value(42); int result = future.then( boost::launch::async, [](boost::future<int> result) { return boost::make_ready_future(result.get()); } ).unwrap().get(); std::cout << "Result is: " << result << std::endl; return 0; } 

In this example, I explicitly used the boost::launch::async policy to start the continuation in a new thread, and I get the expected result from 42.

However , as soon as I replace this policy with boost::launch::deferred , the program seems to be stuck. What am I doing wrong?

NB: Deferred continuation works correctly if I do not unwrap() its value. The problem is specifically in the deployment of deferred continuations.

Answer 1

I think that the future continuation together with the deployment does not make sense. If you create the future with .then , you will get the right future. This way you can call .get () without blocking. That is why I do not see the need for an invested future. However, the way you wrote it should not cause a dead end, and this is probably a mistake.

 #define BOOST_THREAD_VERSION 5 #include <iostream> #include <boost/thread/future.hpp> int main(int argc, char* argv[]) { boost::promise<int> promise; boost::future<int> future = promise.get_future(); promise.set_value(42); int result = future.then( boost::launch::deferred, [](boost::future<int> result) { return result.get(); // get is non-blocking, since it is a continuation } )/*.unwrap()*/.get(); std::cout << "Result is: " << result << std::endl; return 0; } 

With a boost of 1.64, unwrap is still an experimental feature. It would be nice if you reported this behavior to the boost :: thread developer.