Subject: Re: [boost] [thread] Do we can a non backward compatible version with non-blocking futures?
From: Lee Clagett (forum_at_[hidden])
Date: 2015-05-21 11:11:20
On Thu, May 21, 2015 at 9:06 AM, Bjorn Reese <breese_at_[hidden]>
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.
A non-blocking future::then() is convenient for cases like the one Vicente
described, but can the executor framework simulate the same behavior?
Lee