Boost C++ Libraries: Ticket #12293: boost::future::then lambda called before future is ready.

summary changed

anonymous — Thu, 23 Jun 2016 16:43:50 GMT

summary in boost 1.60.0 boost::future::then lambda called before future is ready. → boost::future::then lambda called before future is ready.

owner, status changed

viboes — Mon, 08 Aug 2016 23:03:32 GMT

owner changed from Anthony Williams to viboes
status new → assigned

viboes — Mon, 08 Aug 2016 23:31:44 GMT

Hi, The following shouldn't compile

    auto waitFuture = future1.then([&tmpValue, &promise2](boost::future<void> future){
        assert(future.is_ready());  // this works correctly and is ready.

Do you mean something else instead of future.is_ready?

viboes — Mon, 08 Aug 2016 23:32:57 GMT

You should store the returned future otherwise it will block in

        std::async(std::launch::async, [&promise2, &tmpValue](){
            std::this_thread::sleep_for(std::chrono::seconds(1));
            tmpValue = 1;
            promise2.set_value();
        });

viboes — Mon, 08 Aug 2016 23:41:46 GMT

Replying to viboes:

Hi, The following shouldn't compile
    auto waitFuture = future1.then([&tmpValue, &promise2](boost::future<void> future){
        assert(future.is_ready());  // this works correctly and is ready.
Do you mean something else instead of future.is_ready?

Forget this I didn't saw the future parameter.

viboes — Mon, 08 Aug 2016 23:42:41 GMT

Have you uncommented

//#define BOOST_THREAD_VERSION 4

viboes — Tue, 09 Aug 2016 00:06:11 GMT

I believe the problem is due to the fact that the continuation returns a future<void>. You will need to unwrap the returned future<future<void>>

    }).unwrap().then([&value, &tmpValue](boost::future<void> future){

However, I would like that your code doesn't compile as the continuation should had a boost::future<future<void>> parameter.

When I change the continuation as follows I get the expected error.

    }).then([&value, &tmpValue](boost::future<void>& future){

Note that the future is passed by reference.

This mean that the call to the continuation is getting the embedded future. I will check this.

Jeffrey.Gramowski@… — Wed, 10 Aug 2016 15:52:18 GMT

Replying to viboes:

Have you uncommented
//#define BOOST_THREAD_VERSION 4

Yes this is has been set in the header files for my boost version. I just wanted to document that it is set.

viboes — Mon, 15 Aug 2016 17:21:39 GMT

Have you seen my comment 7?

Jeffrey.Gramowski@… — Mon, 15 Aug 2016 18:00:28 GMT

Replying to viboes:

Have you seen my comment 7?

I tried the unwrap function and it works. But I still think that there is a problem. So either my code shouldn't compile and force the developer to use the unwrap function. Or if boost is going to do the "auto" unwrap functionality than it needs to do it in a way so that it is equivalent to calling the unwrap function.

For now I guess I will call the unwrap function but I still think that something needs to be done here. The current implementation can introduce very hard to find bugs in a system dealing with threads. This is how I ran into this problem. I was trying to track down a deadlock in some multi-threaded code which wasn't suppose to block and I tracked it down to this condition. Note I am also using the executor functionality so that I can control the threads and our threads are not allowed to block.

viboes — Fri, 19 Aug 2016 21:40:36 GMT

I agree that there is a problem. But is is not that the unwrap must be done implicitly.

Boost::future::then was defined before the C++ experimental std::experimental::future::then included in the TS and the original proposal behaved like Boost.Thread. Changing this will be a breaking change and people don't like that.

The problem is that the future<future<void>> is implicitly convertible to future<void>, which must be explicit. I will see what happens if I define the constructor explicit.

milestone changed

viboes — Sat, 03 Sep 2016 11:55:49 GMT

milestone To Be Determined → Boost 1.62.0

https://github.com/boostorg/thread/commit/fc748dbddf33baf2afd1cf33920a6c0da8511f77

status changed; resolution set

viboes — Sat, 03 Sep 2016 11:57:07 GMT

status assigned → closed
resolution → fixed

https://github.com/boostorg/thread/commit/58c6b384cc80ae2af598ab48d16522e71b31ca09