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.

2532. Satisfying a promise at thread exit

Section: 32.10.6 [futures.promise] Status: Open Submitter: Agustín K-ballo Bergé Opened: 2015-09-03 Last modified: 2016-08-06

Priority: 3

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with Open status.

Discussion:

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: 

std::promise<int>{}.set_value_at_thread_exit(42);

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.

[2016-08-03 Chicago]

This is related to 2530(i)

[2016-08-03, Billy O'Neal suggests concrete wording]

Fri AM: Moved to Open

Proposed resolution:

This wording is relative to N4606.

  1. Change 32.10.5 [futures.state] p7 as indicated:

    -7- When an asynchronous provider is said to abandon its shared state, it means:

    1. (7.1) — first, if that state is not ready or scheduled to be made ready at thread exit, the provider

      1. (7.1.1) — stores an exception object of type future_error with an error condition of broken_promise within its shared state; and then

      2. (7.1.2) — makes its shared state ready;

  2. Change 32.10.5 [futures.state] p10 as indicated:

    -10- Some functions (e.g., promise::set_value_at_thread_exit) delay making the shared state ready untilschedule the shared state to be made ready when the calling thread exits. This associates a reference to the shared state with the calling thread. The destruction of each of that thread's objects with thread storage duration (6.7.5.3 [basic.stc.thread]) is sequenced before making that shared state ready. When the calling thread makes the shared state ready, if the thread holds the last reference to the shared state, the shared state is destroyed. [Note: This means that the shared state may not become ready until after the asynchronous provider has been destroyed. — end note]