Boost logo

Boost :

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 (;
>>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at