[Boost-users] Re: Re: Re: Re: Re: thread::thread() in Windows

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2004-12-12 03:33:09

> > 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<thread_impl>). 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<thread_impl>, but it
doesn't mean it's not there)
and: a bunch of global functions

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