Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-10-10 13:17:06

Andrzej Krzemienski wrote
> 2012/10/10 Vicente J. Botet Escriba <

> vicente.botet@

> >
> 
>> Le 10/10/12 10:23, Andrzej Krzemienski a écrit :
>>
>>  Hi,
>>> I can see in the release notes that in Boost 1.52 boost::thread's
>>> destructor calls terminate if joinable, in order to conform to C++11
>>> specification. I am not sure if this is the best course of action.
>>> My understanding -- form the C++ Committee papers and informal
>>> presentations -- is that the reason for introducing a  'terminating
>>> destructor' was the lack of thread cancellation/interruption
>>> functionality.
>>> Thread interruption is supposed to be the preferred behavior for
>>> thread's
>>> destructor. std::thread does not support interruption (for some
>>> reasons),
>>> but boost::thread does (this is already a departure from C++11), so
>>> shouldn't the latter prefer to interrupt a joinable thread in the
>>> destructor?
>>>
>>>
>>>  Hi,
>>
>> yes this is a possible alternative to the standard behavior. But what to
>> do after interrupting, joining? What others think? Anthony?
>>
> 
> My preference would be to join after the interruption. If I remember
> correctly, the argument against joining for std::thread is that there
> would
> be an unexpected hang upon reaching the end of the scope. The argument
> against detaching for std::thread is that the detached thread may be
> holding references to automatic variables defined in the scope of the
> forking thread that we are now exiting.
> 
> I believe that with thread interruption in place the argument against
> joining is mitigated, while the argument against detaching still holds.

Please, could you create a Track ticket?

Thanks,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/thread-terminating-destructor-tp4636872p4636901.html
Sent from the Boost - Dev mailing list archive at Nabble.com.