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