Why Do std::async Futures Have Blocking Destructors?

Why the Block: Reasons Behind the Blocking Destructors of Futures Returned by std::async

When working with asynchronous tasks, the destructor of a future returned by std::async is noted for its blocking behavior, raising questions about its necessity. To delve into this design choice, let's explore the concerns and discussions that led to its implementation.

Herb Sutter's paper, "async, ~future, and ~thread," highlights safety considerations related to blocking destructors. Without this behavior, a "run-away" thread associated with the future could continue executing after its associated state has been destroyed. This lack of control over task completion could potentially lead to memory corruption or other unexpected issues.

Hans Boehm's paper, "Async() future destructors must wait," provides a concrete example of this concern. Without blocking destructors, exception handling or external events could disrupt the expected flow of task execution. As Boehm points out, this could create a security vulnerability where an attacker could manipulate the timing of exceptions to exploit an oversight in scope guards, leading to stack overwriting and process hijacking.

The blocking destructor serves as a safeguard against these potential hazards, preventing the associated thread from continuing execution after the future is destroyed. However, it's important to note that this behavior is specific to futures returned by std::async with an asynchronous launch policy. Other futures, such as those returned by std::promise or futures from parallel algorithms, do not exhibit the same blocking behavior in their destructors.

Despite the safety concerns raised, the blocking destructor of std::async futures has been a topic of ongoing debate within the C standardization committee. Proposed changes to deprecate the blocking behavior or make it non-standard for async futures have not been embraced.

In summary, the blocking destructors of futures returned by std::async is a controversial design choice driven by safety concerns. While it prevents potential issues related to uncontrolled thread execution, it also introduces the need for explicit management of thread lifecycle and scope guards to ensure proper cleanup.

The above is the detailed content of Why Do std::async Futures Have Blocking Destructors?. For more information, please follow other related articles on the PHP Chinese website!