On Thu, May 21, 2015 at 5:13 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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,
Le 23/05/15 19:05, Lee Clagett a écrit : 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