Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 11:46:10

--- In boost_at_y..., Jeremy Siek <jsiek_at_c...> wrote:
> Looks great...
> 
> One thought about the following:
> 
> "You can't call some thread methods for foreign threads of 
execution,
> since the necessary state information may not exist. In particular, 
you
> can not call join() or detach() on foreign threads."
> 
> How about instead of just documenting this restriction, we make it
> impossible for the user to call join() and detach() on a foreign 
thread by
> not providing those functions in the first pace; i.e., use a 
different
> thread class that doesn't have join() and detach().
> 
> Put another way, is there a strong reason to have only a single 
thread
> class?

Not an entirely bad idea.  Instead of an adopt() method you'd have a 
constructor that would take the foreign_thread object (yeah, that 
name needs to change).  The only problem I see is that when you use 
the default constructor (pthread_self() equivalent) the current 
thread may not be a "native" thread (yeah, name change).  How would 
you suggest we work around this?

Bill Kempf