Title
shared_future(future<R>&&) should be allowed to throw
Status
nad
Section
[futures.shared.future]
Submitter
Peter Sommerlad

Created on 2011-04-04.00:00:00 last changed 162 months ago

Messages

Date: 2011-08-16.23:35:18

Proposed resolution:

Apply the proposed resolution of n3269

Date: 2011-08-16.23:35:18

[ 2011 Bloomington ]

Closed as NAD. Rationale to follow by email...

Date: 2011-04-04.00:00:00

Requiring the constructor shared_future(future<R>&& rhs) not to throw is a pessimisation of the case where a future is returned from a call to async(function,launch::deferred) and possible other cases.

Such a future not dealing with multiple threads only needs to keep (a copy of) the function to be called it later. However, creating a shared_future from that future will require more infrastructure, like space for the value of type R, an exception_ptr, and a synchronized reference counter for the shared_future's instances.

Enforcing the constructor shared_future(future<R>&& rhs) not to throw, implies that any implementation of future will need to pre-allocate space for shared_future's infrastructure, that also requires an operating system resource for synchronization, regardless if is ever needed.

All this came up when discussing D/N3267 and Concurrency Working Group decided that the constructor shared_future(future<R>&& rhs) should be allowed to throw.

History
Date User Action Args
2011-08-16 23:35:18adminsetmessages: + msg5853
2011-08-16 23:35:18adminsetstatus: new -> nad
2011-04-20 18:42:43adminsetmessages: + msg5721
2011-04-04 00:00:00admincreate