Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at