On Thu, May 21, 2015 at 9:06 AM, Bjorn Reese
On 05/19/2015 01:58 AM, Vicente J. Botet Escriba wrote:
My question is if the Boost community will accept (or even wants) a
breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures.
It is unclear to me exactly what the breaking changes are. Are they limited to .then()?
boost::future::then() and boost::async() would no longer block in the destructor of the returned future if the worker thread has not yet-completed. I read through the proposals for std::async, and it appears the standards committee made a blocking destructor mainly to reduce potential bugs. It prevents a thread from continuing to execute after main, and prevents exception unsafe code: const auto work = boost::async(boost::launch::async, [&]() { ....}); ... do stuff - an exception could make captured variables go out of scope ... work.get(); Until recently, boost::future::then didn't properly block in the destructor of the returned future anyway. The 1.58 release may have already changed behavior in some code bases if the documentation for boost::future::then was not read. A non-blocking future::then() is convenient for cases like the one Vicente described, but can the executor framework simulate the same behavior? Lee