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)
and: thread_ref class (which might just be a shared_ptr
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.
The same in the thread_ref design. The thread_impl is kept alive, while the thread_ref is created and deleted at the user's will.
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().
That pops another question: what to do with the main thread? What will happen if the user will call current_thread() while in the main thread? You somehow have to create a thread_impl of the main thread before the start of main() function, and store it in the tss. Perhaps using global/static objects that the compiler will care for initilizing before main()? Very dangerous (especially with Windows DLLs). Of course you can ask me the same question: what to do in such case using the noncopyable design? Well, I was hoping you didn't ask... :-) First, if you can find a solution to this problem with your design, then maybe I can use the same technique and store a thread object representing the main thread, and also supply a thread& get_main_thread() function. Alternatively, I can say that there is no main thread object. Is this a bad solution? What would I loose? I'd loose the opportunity to do 'main_thread.join()', but that just might be a good thing. I'd also loose the possibility to comapre the address of the main thread object to addresses of other threads. Hmmm... Well, I hope that's not a problem... Definitely something to think about.