Hello boost::thread experts, does the 'thread_ref-design' as discussed previously enable the following scenario ? <code start> struct thread_class_1 { thread_ref tr; void operator()() { tr = get_current_thread_ref(); // view from *inside* a thread ... } } ; ... thread_class_1 thread_functor_1; boost::thread thread_1(thread_functor_1) ; ... // assume the thread really started in the meantime ... thread_ref tr_1 = thread_functor_1.tr; // view from *outside* a thread // assume the thread is still working ... thread_ref tr_2 = thread_1.get_thread_ref(); // view from *outside* a thread ... <code end> Now tr_1 == tr_2 evaluates to true. To my understanding the current implementation of boost::thread does not allow easy comparison of threads from *inside* and *outside*. Grouping the boost::thread members m_thread,m_id,.. into a comparable type (e.g. named thead_id) and exposing this id at least 'protected' would make user extensions more flexible. Thanks for any reply, Martin. Peter Dimov wrote:
Yuval Ronen wrote:
I believe that we are going a bit off the topic here, but I'll go there with you.
What you are suggesting, is that what we now know as 'thread' will be transformed into 'thread_impl' and will be hidden from the user, which will only know about thread_ref (actually a shared_ptr
). First of all, in no way do I dismiss this proposal. But what is the difference between this and the current design? The difference is:
Current design:
(thread data, including function object) (thread class, noncopyable)
thread_ref design:
(thread data)
The current design has two logical object per thread, one that remains alive until the thread finishes execution, another that is created by the user and can be destroyed at any time.
Another thing: if we want a thread_ref current_thread(); function, how will it be implmented?
A thread_ref is held in thread-specific storage (keeping the thread object alive for the lifetime of the thread as a side effect) and is returned by current_thread().