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