Re: thread_group

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