From: delfjk (jukka.katajaharju_at_[hidden])
Date: 2002-03-06 16:01:44
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., "delfjk" <jukka.katajaharju_at_r...> wrote:
> > Why is it that thread_group do not have a remove_all method?
> > It would make the thread_group usage as a class variable much
more
> > easier.
> >
> > Here is a proposal for a implementation (which includes also some
> > other minor changes):
> >
> > class thread_group : private noncopyable
> > {
> > public:
> > thread_group(bool join_threads_on_destroy = false);
> > ~thread_group();
> >
> > thread* create_thread(const function0<void>& threadfunc);
> > void add_thread(thread* thrd);
> > void remove_thread(thread* thrd);
> > void join_all();
> > void remove_all(bool join_threads = true);
> > private:
> > std::list<thread*> m_threads;
> > mutex m_mutex;
> > bool m_join_threads_on_destroy;
> > };
>
> [snip implementation code]
>
> An addition of a remove_all() method is not a bad idea. However, I
> don't care for the boolean join_threads parameter. Firstly, this
> just isn't consistent with the remove_thread() routine, where the
> thread is removed with out joining. Second, since this is a very
> limited form of a container I think that joining on removal, even
if
> it were included, should default to false. Third, there's very
> little "burden" on just calling join_all() prior to remove_all(),
so
> I see little motivation to allow joining on removal.
>
> Along the same reasoning, I don't care for the "join threads on
> destroy" addition either. Like in the recent discussion of the
> Boost.Signals library, if you were to include such a concept it
> should be in a seperate class... controlling_thread_group perhaps
for
> a name. However, the motivation for Boost.Signals, where you'll
have
> to maintain several "connections" within a class making explicit
> disconnections burdensome, doesn't really exist here. So I'm not
> sure I care for adding a controlling_thread_group either.
>
> Bill Kempf
I added those boolean flags just to get joining more automatic, but
you are right, that can be done elsewhere.
But remove_all method would still be a nice feature to have in
boost::thread_group, since it opens the possibility to use
thread_group class for example with a thread proxy functor that takes
other functor as parameter to be asynchronically executed in a own
thread (created with create_thread method). And so it would be nice
to join all of these threads later on and still use the same
thread_group instance after that.
...
std::for_each(int_vector.begin(), int_vector.end(), foo_ns::thread_fun
(foo_ns::other_fun_obj(), thread_group_instance_));
...
-J.Katajaharju