This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.
Section: 30.6.6 [futures.promise] Status: Open Submitter: Agustín K-ballo Bergé Opened: 2015-09-03 Last modified: 2016-08-06
View other active issues in [futures.promise].
View all other issues in [futures.promise].
View all issues with Open status.
promise::set_value_at_thread_exit and promise::set_exception_at_thread_exit operate on a shared state at thread exit, without making the thread participate in the ownership of such shared state.Consider the following snippet:
Arguably, since the promise abandons its shared state without actually making it ready, a broken_promise error condition should be stored in the shared state. Implementations diverge, they either crash at thread exit by dereferencing an invalid pointer, or keep the shared state around until thread exit.
This is related to 2530
[2016-08-03, Billy O'Neal suggests concrete wording]
Fri AM: Moved to Open
This wording is relative to N4606.
Change 30.6.5 [futures.state] p7 as indicated:
-7- When an asynchronous provider is said to abandon its shared state, it means:
(7.1) — first, if that state is not ready , the provider
(7.1.1) — stores an exception object of type future_error with an error condition of broken_promise within its shared state; and then
(7.1.2) — makes its shared state ready;
Change 30.6.5 [futures.state] p10 as indicated:
-10- Some functions (e.g., promise::set_value_at_thread_exit)
delay making the shared state ready untilthe calling thread exits. The destruction of each of that thread's objects with thread storage duration (126.96.36.199 [basic.stc.thread]) is sequenced before making that shared state ready.