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