Le 13/10/15 00:04, Agustín K-ballo Bergé a écrit :
On 10/12/2015 6:42 PM, Vicente J. Botet Escriba wrote:
Le 12/10/15 15:57, Agustín K-ballo Bergé a écrit :
On 10/11/2015 9:02 PM, Vicente J. Botet Escriba wrote:
Hi,
all is in the title.
Don't they all? Blocking in the future destructor is what the standard mandates.
I'm confused. Do they block on the future destructor or the destructor of the shared state?
They may block on the destructor of the shared state:
30.6.4 [futures.state]/5 When an asynchronous return object or an asynchronous provider is said to release its shared state, it means: - [...] - these actions will not block for the shared state to become ready, except that it may block if all of the following are true: the shared state was created by a call to `std::async`, the shared state is not yet ready, and this was the last reference to the shared state.
You can think of `std::async` conceptually being implemented as having an `std::thread` within the shared state, which chooses to join on destruction to avoid termination.
The note of the standard says on the destructor of the returned future
"[ Note: If a future obtained from std::async is moved outside the local scope, other code that uses the future must be aware that the future’s destructor may block for the shared state to become ready. — end note ]"
Notes are not normative. A future's destructor is where you'd most likely notice the block, but it could happen during assignment too.
Thanks Agustin for clarifications, Vicente