Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 12:10:00

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> On Sat, 19 Jan 2002, bill_kempf wrote:
> willia>
> willia> Not an entirely bad idea.  Instead of an adopt() method 
you'd have a
> willia> constructor that would take the foreign_thread object 
(yeah, that
> willia> name needs to change).  The only problem I see is that when 
you use
> willia> the default constructor (pthread_self() equivalent) the 
current
> willia> thread may not be a "native" thread (yeah, name change).  
How would
> willia> you suggest we work around this?
> 
> First, let me ask a question. How did you plan on handling this? 
(with
> your latest thread stuff, not including my suggestion) How do you
> tell whether the current thread is a boost thread or a platform 
thread?

The boost::thread class maintains state information that's placed in 
thread local storage (and then simple pointers to this data are 
placed in each object instance).  If a thread was not created using 
Boost.Threads this thread local data won't exist (and the pointer in 
the object will be set to NULL).  The fly in the ointment comes about 
when we need to call methods that require this Boost.Threads specific 
state data for the "platform" threads.  Thus the need to "adopt" such 
threads.  The adopt() method will allocate the needed state 
information and place it in the thread local storage, thus promoting 
a "platform" thread to a "boost" thread.

Because of the different requirements for cleaning up the various 
state information (platform and Boost.Threads) it's up to the 
programmer to insure that adoption "follows the rules".  If it's 
a "platform" thread then platform specific methods must be used to 
manage the state's lifetime and if it's a "boost" or "adopted" thread 
then Boost.Threads specific methods must be used.  So we can't just 
arbitrarily adopt threads implicitly.

Bill Kempf