This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

1047. Ensure that future's get() blocks when not ready

Section: 30.6.7 [futures.unique_future] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2016-02-10

Priority: Not Prioritized

View all other issues in [futures.unique_future].

View all issues with Resolved status.

Discussion:

Addresses UK 334 [CD1]

Behaviour of get() is undefined if calling get() while not is_ready(). The intent is that get() is a blocking call, and will wait for the future to become ready.

[ Summit: ]

Agree, move to Review.

[ 2009-04-03 Thomas J. Gritzan adds: ]

This issue also applies to shared_future::get().

Suggested wording:

Add a paragraph to 30.6.8 [futures.shared_future]:

void shared_future<void>::get() const;

Effects: If is_ready() would return false, block on the asynchronous result associated with *this.

[ Batavia (2009-05): ]

It is not clear to us that this is an issue, because the proposed resolution's Effects clause seems to duplicate information already present in the Synchronization clause. Keep in Review status.

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2997.

Proposed resolution:

Add a paragraph to 30.6.7 [futures.unique_future]:

R&& unique_future::get(); 
R& unique_future<R&>::get(); 
void unique_future<void>::get();

Note:...

Effects: If is_ready() would return false, block on the asynchronous result associated with *this.

Synchronization: if *this is associated with a promise object, the completion of set_value() or set_exception() to that promise happens before (1.10) get() returns.