Re: [boost] [thread] terminating destructor

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

Le 23/10/12 17:56, Daniela Engert a écrit :
> Am 23.10.2012 11:44, schrieb Andrzej Krzemienski:
>> 2012/10/23 Rob Stewart <robertstewart_at_[hidden]>
>>
>>> On Oct 21, 2012, at 2:28 AM, "Vicente J. Botet Escriba" <
>>> vicente.botet_at_[hidden]> wrote:
>>>
>>>> Le 20/10/12 20:41, Andrzej Krzemienski a écrit :
>>>>> 2012/10/20 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
>>>>>
>>>>> What do you think of adding a thread_guard class that could interrupt
>>> and
>>>>>> join on the destructor?
>>>>>>
>>>>> By "adding", do you mean adding it to Boost? I suggested this
>>> interruption
>>>>> because I believed (apparently incorrectly) that class thread
>>> represents a
>>>>> tool ready to be used by "end-user" programmers. After this 
>>>>> discussion I
>>>>> realize that thread is a low-level primitive that you use for 
>>>>> building
>>>>> high-level concurrency constructs, but would rather not use it 
>>>>> directly.
>>>>> Following this view, anyone can build their own abstraction atop
>>>>> boost::thread. I do not think the above thread_guard should be added
>>> into
>>>>> Boost. If I need it I can write it myself (and I would probably 
>>>>> write it
>>>>> differently; e.g. using variadic forwarding constructor).
>>>> I agree that these classes are easy to write by the user. Maybe adding
>>> them as examples of use in the documentation could help the user.
>>>
>>> I don't agree with the it's-easy-to-write-so-don't-add-it-to-Boost
>>> philosophy. By adding such a class to Boost, you highlight the idea to
>>> those that otherwise hadn't thought of it, and you standardize the 
>>> I/F and
>>> semantics.
>>>
>>
>> I understand your reasoning, but the situation with boost::thread (and
>> std::thread) is very particular: 'end-user' programmers will not use 
>> naked
>> threads; they will also not use "thread guards" (as described above)
>> because they are still too low-level, aren't they?
>
> Even Bjarne Stroustup doesn't pretend to know what 'end-users' do. 
> Most likely, nobody does.
>
> Looking at the code base in our company (VC10 or VC11 only) I can say 
> that none of my colleagues ever used something higher-level than 
> boost::thread - mostly for historical reasons and an 'it ain't broke 
> so leave it alone' attitude. If a tool like 'thread_guard' or the like 
> came pre-packaged with Boost, they'd happily swallow it rather than 
> rolling their own.
>
>
Hi,

I have created two tickets to track this possible additions:

https://svn.boost.org/trac/boost/ticket/7540: Add a helper class that 
interrupts a thread and join it on destruction
https://svn.boost.org/trac/boost/ticket/7541: Add a thread wrapper class 
that interrupts and join on destruction

While the scoped_thread class defined in C++ Concurrency in Action is a 
strict scoped class that doesn't allows any change in the wrapped 
thread, I think that making the interface thread compatible is also a 
good option. This doesn't means that a strict scoped thread has no use.

Best,
Vicente