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