On Sun, Apr 7, 2013 at 12:47 AM, Stefan Strasser <strasser@uni-bremen.de> wrote:

your example is not easy to read. IIUC, after execute(), the work queue is emptied and the last shared_ptr to struct K goes out of scope. K contains your promise and the future associated with it is accessed after the promise has been destroyed.
try a breakpoint in the destructor of K to make sure, I don't have tbb installed to test.

In my last message I provided a simplified version without K. I just make a shared_ptr of the promise.

As the use of the shared_ptr is inside the lambda and I push it in the queue, and I captured it by copy, I know the promise is alive

until both the lambda and the do_some_work() function are both executed fully.

So the promise is destroyed before setting the value to the future.

In doubt, I also tested by making the future before pushing the lambda. But it's the same thing going on in sequential code like the one I provide in the test.

When debugging, I can see that the future is set when the promise.set_value() is called.

However, it seem that the return of future.get() is wrong, but when I go step by step inside the get() implementation, I don't see where the value is lost.

Could it be that the "reset" of boost::future corrupt the returned type?

I'm currently looking for other clues.

Joel Lamotte