Subject: Re: [boost] [thread] terminating destructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-13 19:12:40
Le 13/10/12 23:17, Andrzej Krzemienski a écrit :
> 2012/10/13 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>
>> Le 13/10/12 16:08, Andrzej Krzemienski a écrit :
>>
>> std::future does
>>>>> join without interruption. What does boost::future do? I think it should
>>>>> interrupt and join (or perhaps detach as per N3451).
>>>>>
>>>>> I don't understand this. Could you clarify?
>>>>>
>>>> Sorry, I tried to say too much in one sentence. While std::thread's
>>> destructor terminates for joinable thread, std::future's destructor
>>> sort-of
>>> joins with the (implied) thread: it waits until the job is done. So we
>>> already have a potentially surprising suspension upon leaving the scope.
>>>
>> I guess you are referring to the case the std::future is created by async
>>
>> 0.
>>
>> If the implementation chooses the launch::async policy,
>>
>> *
>>
>> — a call to a waiting function on an asynchronous return object
>> that shares the shared state created
>>
>> by this async call shall block until the associated thread has
>> completed, as if joined (30.3.1.5);
>>
>>
>> C++ International Standard Otherwise
>>
>> ~std::future();
>> Effects:
>> — releases any shared state (30.6.4);
>> — destroys *this.
>>
>> Could you explain me what waiting function is called on the future
>> destructor that needs to block until the completion of the associated
>> thread?
>
> It is not any waiting function mentioned explicitly. It is the requirement
> in 30.6.8 para 5: "If the implementation chooses the launch::async policy,
> [...] the associated thread completion synchronizes with the return from
> the first function that successfully detects the ready status of the shared
> state or with the return from the last function
> that releases the shared state, whichever happens first."
>
Why the future destructor should be the last function that release the
shared state?
Best,
Vicente