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: Lee Clagett (forum_at_[hidden])
Date: 2015-05-23 13:05:08

On Thu, May 21, 2015 at 5:13 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

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

boost::async and boost::future::then seem error prone due to ownership of
the execution handle. If the destructor of the boost::future automatically
releases ownership, the execution handle cannot be managed. If an executor
was provided to boost::async and boost::future::then, the lifetime of the
executor could be controlled separately from the returned future. It should
prevent threads after main, which never seem like a good idea.
Unfortunately, if client code throws before a boost::future::get() then
stack references can still be invalidated with the executor (see my prior
post) - but there are a number of ways to achieve this incorrect behavior
anyway.

If boost::future::~future detaches the execution handle, its still possible
to create an RAII wrapper that blocks if that behavior is desired. I don't
think the opposite is possible, so the change is more flexible.

Lee