Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-14 08:18:00

2012/10/14 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>

> 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?

Indeed, it doesn't have to be the destructor. I misinterpret this
requirement. Sorry. I no longer claim that future's destructor blocks in
this case. Although, others (like Herb) seem to claim that. I will
investigate that.

Regards,
&rzej