Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2012-10-13 05:35:19

On Oct 12, 2012, at 4:24 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

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

That seems a reasonable argument.

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

That seems like too much nannyism. C++ already has many ways to do similar things, so why be so concerned with this one case?

>> I believe that with thread interruption in place the argument against
>> joining is mitigated, while the argument against detaching still holds.
> 
> 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.

I agree. Hanging like that during stack unwinding would be painful. At least with terminate, you'd realize the problem.

MT requires knowledge and skill. Too much handholding gets in the way and encourages naive users to get in over their head.

If someone wants a thread to interrupt and join on destruction, they need only put the thread object in another object and have that destructor interrupt and join.

___
Rob