Re: thread_group

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-03-05 10:21:54

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