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-24 07:35:17

Le 23/05/15 19:05, Lee Clagett a écrit :
> 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.
Are talking here of blocking or non-blocking futures?
> If the destructor of the boost::future automatically
> releases ownership, the execution handle cannot be managed.
Why?
> 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.
I have a branch on which the executors are lightweight. In this branch, 
the future created using asyn/then executor have a reference to the 
executor. I will create a branch with the non-blocking futures and the 
lightweight executors.
> It should
> prevent threads after main, which never seem like a good idea.
Sorry, I don't understand, it should prevent what?
> 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.
>
>
Could you tell us more?

Thanks for all your comments,
Vicente