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.
get()
blocks when not readySection: 32.10.7 [futures.unique.future] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2021-06-06
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 [futures.shared_future]:
void shared_future<void>::get() const;Effects: If
is_ready()
would returnfalse
, 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 [futures.unique_future]:
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();Note:...
Effects: If
is_ready()
would returnfalse
, block on the asynchronous result associated with*this
.Synchronization: if
*this
is associated with apromise
object, the completion ofset_value()
orset_exception()
to thatpromise
happens before (1.10)get()
returns.