Boost logo

Boost :

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.
> 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at