2012/10/23 Rob Stewart <robertstewart@comcast.net>
On Oct 21, 2012, at 2:28 AM, "Vicente J. Botet Escriba" < vicente.botet@wanadoo.fr> wrote:
2012/10/20 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
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
Le 20/10/12 20:41, Andrzej Krzemienski a écrit : 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