Re: [boost] [thread] terminating destructor

Subject: Re: [boost] [thread] terminating destructor
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-23 05:44:49

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? 'end-user' programmers
(IMHO) would prefer higher abstractions, e.g "do another task in parallel"
(use async() for that), or perform some algorithm on a Range in parallel
(they will use some 'concurrent algorithms library' for that).

The only use of naked threads (again, IMHO) is to build these higher level
abstractions, but in this case a guard that interrupts and joins is likely
not the thing you would want to use: first, you are already inventing
something on your own and have to write a custom wrapper, second, there are
too many possible semantics of such wrapper: "interrupt and join",
"interrupt and detach", "detach without interruption" -- should Boost
library provide wrappers for all these possible needs?

On the other hand, giving such a wrapper as an example in documentation
already highlights the idea to some extent.

Regards,
&rzej