"vicente.botet" <vicente.botet@wanadoo.fr> writes:
It should be great if the Thread library documentation included a History section and include the changes since 1.35 that we can already found in the Version 1.36.0 page (http://beta.boost.org/users/news/version_1_36_0)
Good idea.
The create_thread interface evolution is not present in the doc. Replace thread* create_thread(const function0<void>& threadfunc); by template<typename F> thread* create_thread(F threadfunc);
Oops.
BTW, as you have enhanced the interface for the thread construction
template <class F,class A1,..., class An> thread(F f,A1 a1,..., An an);
why not to apply the same schema to the create_thread function of the thread_group class?
There's a trac issue for that. I haven't got round to it yet.
Just one minor sugestion: The guard on the create_thread function should be declared after the thread creation to limit the scope of the mutex lock.
template<typename F> thread* create_thread(F threadfunc) { std::auto_ptr<thread> new_thread(new thread(threadfunc)); { boost::lock_guard<mutex> guard(m); threads.push_back(new_thread.get()); } return new_thread.release(); }
That's a good idea.
Reading the code we see that the thread_group class is thread safe using an internal mutex. Is this is part of the contract it is not documented? In addition an application creating/adding all the threads of a group in one thread do not needs this thread safety. Following the C++ phylosophy "don't pay for what you don't use", should't this class be parameterized by a synchronization policy.
Maybe. It's been thread-safe with an internal lock for as long as I've been aware of it though. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL