Re: [boost] [thread] request for interest in new c++1y features

Subject: Re: [boost] [thread] request for interest in new c++1y features
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-21 10:04:14

Le 21/10/12 15:41, Evan Wallace a écrit :
> Bjorn Reese <breese <at> mail1.stofanet.dk> writes:
>> The main problem is the duration of the continuation. If the function
>> passed to std::async finishes before we call future.then, then the
>> continuation will be executed by the calling thread. This means that
>> the calling thread is blocked while the continuation is executed, which
>> is a problem if the continuation is slow. Then we might as well call
>> the two functions synchroneously.
> My understanding is that the continuation will be *launched from* the
> calling thread, but the thread on which the continuation is *actually
> run* is determined by the launch policy.
> Perhaps an example will help to explain what I mean by this:
>
> #include <future>
> using namespace std;
> int main() {
>      //Compute some value on a different thread.
>      //The launch policy defaults to launch::async | launch::deferred
>      future<int> f1 = async([]() { return 123; });
>
>      //Call wait() to ensure that this example hits the situation
>      //where the .then call occurs after the future is already
>      //available.
>      f1.wait();
>
>      //The continuation will be run (as if) by std::async,
>      //and so will not block the current thread if an
>      //appropriate launch policy is selected.
>      //The launch policy is inherited from the original
>      //async call (unless explicitly overridden).
>      future<int> f2 = f1.then([](future<int> f) {
>          return expensive_computation(f.get());
>      });
> }
>
I see. I missed the inheritance from the original. Unfortunately the 
Boost.Thread futures implementation doesn't stores yet the way the 
future was created and so I'm unable to implement this as such.
I have a task pending, implement async with launch::deferred. Once I 
could take in account the inheritance of the launch policy. Until that I 
could use the launch::async policy instead of calling the continuation 
on the same thread.

Thanks for your interesting comments,
Vicente