Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-12 16:24:19

Le 10/10/12 14:56, Andrzej Krzemienski a écrit :
> 2012/10/10 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>
>> 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.
>

Hi,

I've though more about your suggestion, and it seems to me that it has 
the same drawbacks as joining directly. The point is that interrupting a 
thread doesn't ensures that the thread will finish soon, as the thread 
could not call any interruption point, so that joining them later could 
take an undefined time.

What do you think?

Best,
Vicente