Why is the destructor of a future returned from `std::async` blocking?

Blocking destructors of futures returned by std::async and of threads: That’s a controversial topic. The following list of papers in chronological order reflects some of the discussions by the members of the committee:

Although there was a lot of discussion, there are no changes planned for C++14 regarding the blocking behaviour of the destructors of std::future and std::thread.

Regarding your question, the most interesting paper is probably the second by Hans Boehm. I quote some parts to answer your question.

N3679: Async() future destructors must wait

[..] Futures returned by async() with async launch policy wait in their destructor for the associated shared state to become ready. This prevents a situation in which the associated thread continues to run, and there is no longer a means to wait for it to complete because the associated future has been destroyed. Without heroic efforts to otherwise wait for completion, such a “run-away” thread can continue to run past the lifetime of the objects on which it depends.

[Example]

The end result is likely to be a cross-thread “memory smash”. This problem is of course avoided if get() or wait() is called [..] before they [the futures] are destroyed. The difficulty [..] is that an unexpected exception may cause that code to be bypassed. Thus some sort of scope guard is usually needed to ensure safety. If the programmer forgets to add the scope guard, it appears likely that an attacker could generate e.g. a bad_alloc exception at an opportune point to take advantage of the oversight, and cause a stack to be overwritten. It may be possible to also control the data used to overwrite the stack, and thus gain control over the process. This is a sufficiently subtle error that, in our experience, it is likely to be overlooked in real code.

Update: Michael Wong’s Trip Report also contains some interesting information regarding the outcomes of the meeting in September 2013:

The View from the C++ Standard meeting September 2013 Part 2 of 2.

On the issue that async destructors should not block we devoted a great deal of discussion on it. [..] The only position that received considerable support was [..] giving advisory that future destructors will not block, unless returned from async, making it the notable exception. [..] After significant discussion, the only part that we tried to carry was N3776, an attempt to clarify the position that ~future and ~shared_future don’t block except possibly in the presence of async. There was an attempt to issue a deprecation along the lines of C. Deprecate async without replacement. This motion was actually almost put forward. But [..] it died even before it reached the operating table.

Leave a Comment