Re: [boost] [thread] Do we can a non backward compatible version with non-blocking futures?

Le 21/05/15 17:11, Lee Clagett a écrit :

On Thu, May 21, 2015 at 9:06 AM, Bjorn Reese wrote:

...

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. Yes 1.58 implemented exactly what was documented. block on destructor.

A non-blocking future::then() is convenient for cases like the one Vicente described, but can the executor framework simulate the same behavior?

Please , could you elaborate? Vicente