Boost C++ Libraries: Ticket #9711: future continuation called twice

attachment set

ikispal@… — Tue, 25 Feb 2014 12:51:53 GMT

attachment → boost_future.cpp

cc set

ikispal@… — Tue, 25 Feb 2014 12:53:13 GMT

cc ikispal@… added

ikispal@… — Tue, 25 Feb 2014 13:14:32 GMT

The second time the continuation is called an empty (invalid) future is passed to it. (I suppose the guts of the future was stolen by move() during the previous call.)

ikispal@… — Tue, 25 Feb 2014 14:46:54 GMT

What is even worse: if the future returned by then() is not void, then:

the first call of its get() will call the continuation a second time (as described above) and will return with the result of this erroneous second invocation!

the second call of its get() will return with an empty (default constructed?) value!

owner, status changed

viboes — Tue, 25 Feb 2014 22:37:02 GMT

owner changed from Anthony Williams to viboes
status new → assigned

Thanks for catching this issue. I have not tested enough deferred futures with continuations.

viboes — Wed, 26 Feb 2014 05:53:03 GMT

After reading more carefully the ticket and the example code, the single call must be on the call to

futr2.get();

as the then has been called with a deferred policy, and not on the promise set_value().

component, milestone changed

viboes — Wed, 26 Feb 2014 06:37:56 GMT

component threads → thread
milestone To Be Determined → Boost 1.56.0

Just commenting the call to execute in future_deferred_continuation_shared_state should fix the issue.

    virtual void launch_continuation(boost::unique_lock<boost::mutex>& ) {
      //execute(lk);
    }

anonymous — Wed, 26 Feb 2014 09:27:19 GMT

If you want to start the continuation in the get() of futr2 that would mean that this will not start the continuation at all:

auto futr1 = promise1.get_future();
auto futr2 = futr1.then({});
promise1.set_value();

Is this intended? (Please note that the only get() call here is inside the continuation itself.) What about this:

auto futr1 = promise1.get_future();
auto futrLast = futr1.then({}).then({}).then({});
promise1.set_value();

Do I always have to keep track which future is at the end of the line and call its get()? My main use-case would be to not block at all, but this way I am forced to call get() and thus block in it.

viboes — Wed, 26 Feb 2014 17:59:07 GMT

Replying to anonymous:

If you want to start the continuation in the get() of futr2 that would mean that this will not start the continuation at all:
auto futr1 = promise1.get_future();
auto futr2 = futr1.then({});
promise1.set_value();

Here you create a continuation that is asynchronously called when the futr1 is ready and so it will be called independently of whether you get the value of futr2 or not. You example used deferred

auto futr2 = futr.then(boost::launch::deferred, ...);

so that the continuation should be called only when you call futr2.get().

Is this intended?

This is how I understand it. Maybe you can disagree.

(Please note that the only get() call here is inside the continuation itself.) What about this:
auto futr1 = promise1.get_future();
auto futrLast = futr1.then({}).then({}).then({});
promise1.set_value();
Do I always have to keep track which future is at the end of the line and call its get()?

The last one is stored in futrLast. What i sthe problem?

My main use-case would be to not block at all, but this way I am forced to call get() and thus block in it.

Then you must use launch::async.

viboes — Wed, 26 Feb 2014 21:13:12 GMT

https://github.com/boostorg/thread/commit/d2a65d242751cece17e28b7cc6d7bfb395e900e8 https://github.com/boostorg/thread/commit/a7400061c6a2851f65edbf5e536e31e7a2a62918

status changed; resolution set

viboes — Wed, 12 Mar 2014 22:45:09 GMT

status assigned → closed
resolution → fixed

anton.matosov@… — Fri, 10 Oct 2014 11:55:12 GMT

Commit d2a65d242751cece17e28b7cc6d7bfb395e900e8 completely disables functionality of the .then(launch::deferred, ...) continuation...

I will open a separate ticket with the test code to reproduce the issue.

viboes — Sun, 12 Oct 2014 13:51:43 GMT

I have added test for deferred then and every thing is OK https://github.com/boostorg/thread/commit/3e28ea806c412c697f134fdaacbccc9b64213426

anton.matosov@… — Mon, 13 Oct 2014 09:15:52 GMT

Ok. I see now that I was using it differently and possibly wrong way. In the old implementation 'deferred' continuation was called synchronously from the thread that sets satisfies the future. And I am relying on this functionality. However deferred means that it should be called when feature value is retrieved, which now looks correct, but it is not that obvious when you start with future continuations as it is not described anywhere.

Is there any way to achieve the functionality of the sync call from the 'satisfier' side?

viboes — Fri, 17 Oct 2014 06:43:50 GMT

You have the extension promise::set_wait_callback

http://www.boost.org/doc/libs/1_56_0/doc/html/thread/synchronization.html#thread.synchronization.futures.reference.promise.set_wait_callback