On Wed, May 27, 2015 at 1:57 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 26/05/15 23:43, Lee Clagett a écrit :
On Sun, May 24, 2015 at 7:35 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
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@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?
I was referring to non-blocking futures.
If the destructor of the boost::future automatically
releases ownership, the execution handle cannot be managed.
Why?
It was incorrect of me to say that the execution handle cannot be
managed (see below). I thought the separate executor argument to boost::async could make it more obvious that the executor object would control the lifetime of the execution thread, and that it could prevent possible data races. I doubt it will make data races to stack references easier to identify, but it should help prevent threads after main, since the executor object could force all execution threads to stop on its destruction instead. It wasn't obvious previously, but I was wondering whether the detach on future destruction should only be enabled when boost::async takes an executor overload.
It should
prevent threads after main, which never seem like a good idea.
Sorry, I don't understand, it should prevent what?
Static destruction could be complicated if there were multiple execution
threads after main. That was another issue brought up about not blocking on destruction for the std async/future versions.
So, you are saying that async() should return a blocking future if there is no executor parameters, and a non-blocking when the executor is given, isn't it?
Yes, that is what I am saying. My thinking was that the behavior for the corresponding std functions were chosen as the least worst alternative, and that boost should follow that behavior. When an executor is provided as an argument, the situation is slightly different, and the problems that led to the blocking decision _might_ go away. The behavior differences between overloads might provide more confusion though. Lee