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

Subject: Re: [boost] [thread] Do we can a non backward compatible version with non-blocking futures?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-05-21 17:13:22

Le 21/05/15 17:11, Lee Clagett a écrit :
> 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.
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