Re: [boost] Re: Boost.Threads - name of the "thread" type

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-21 16:19:16

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > From: <williamkempf_at_h...>
> > > ... Beman sugggests ...
> > > So in my mind, either change the class name to something that 
> denotes 
> > > identifier, handle, or the like, or change the semantics to be 
> more 
> > > thread-like and less thread_id like.   Make it noncopyable, and 
> so 
> > > forth.  I don't entirely see how to do that.  I guess a 
> create_thread 
> > > static or free function could return a pointer to a thread 
> object.  
> > > Then delete of the pointer would kill the thread.  But it would 
> have to be 
> > > a weak pointer because the thread might already be dead and thus 
> the 
> > > object already destroyed. 
> > > 
> > >     class thread : noncopyable 
> > >     { 
> > >         //  All constructors private, so thread::create() 
> > >         //  is the only way to create a thread 
> > >         thread(); 
> > >         ... 
> > >     public: 
> > >         ~thread();  // assert(*this != self()) 
> > > 
> > >         bool is_alive() const; 
> > >         void join(); 
> > > 
> > >         static thread * create(void (*threadfunc)(void*), void* 
> > > param); 
> > >         static thread & self(); 
> > >         static void join_all(); 
> > >         static void sleep(const xtime& xt); 
> > >         static void yield(); 
> > >     }; 
> > 
> > I understand noncopyable, but why force heap allocation via the
> > create call?
> > 
> > Must constructing a thread automatically start it running?  Why
> > not a separate start() member?
> 
> In general, I've never cared for this approach.  Why have a two 
> phased construction?

It can be nice to first set up bunch of threads and then start them.

> > Is the ugly (void (*threadfunc)(void*), void* param) really needed?
> > Why not (void (*threadfunc) (thread*)), or even a virtual run()
> > method?
> 
> Either approach requires derivation from a base "thread" class (in 
> quotes because the name is truly what's being discussed here, despite 
> this sideline).  This adds complexity with out adding any real 
> functionality, so I don't like either of these approaches.  However, 
> the signature will be changing very shortly to make use of 
> Boost.Function.
>  
> > Must destroying a thread object stop thread execution?  How?  Note
> > that java was forced to deprecate it's Thread.stop() method in
> > favor of Thread.interrupt(), which just throws an exception on
> > the thread.
> 
> Actually, I have no plans at this time to support thread cancellation 
> (to use terminology more familiar to most folks here).  Thread 
> cancellation is a slippery slope in C++ for reasons beyond just those 
> discovered in Java.

Then if ~thread() doesn't stop execution, and the thread* isn't
needed by the threadfunc, I don't see why not to allow thread
objects to be constructed wherever, and even be copied.

> > What is the difference between join() and join_all()?  Should they
> > take an optional timeout?
> 
> Join waits on a thread while join_all waits on all currently 
> executing threads.  The join_all method is really just a 
> convenience... one that may deserve seperate discussion on it's 
> appropriateness.  Along these lines I think it might also be worth 
> discussing a thread_group concept similar to that in Java which would 
> accomplish the same thing as join_all.
> 
> As for time outs, I purposely left them out since not all threading 
> libraries support them.  However the current implementation shows 
> that it would be trivial to include a timeout even on these 
> platforms.  If a real need is found for this I can add this with out 
> breaking anything.
>  
> > Is yield() intended to allow non-premptive implementations?
> 
> No.  In premptive implementations it's often useful to relinquish a 
> threads current timeslice early in order to allow other threads 
> access to a CPU earlier.  This is nothing more than a performance 
> optimization, but it's an important one.  On many systems a yield() 
> is equivalent to a sleep() of zero duration.

I think for standardization purposes it would be a good thing to
allow non-preemprive implementations, as does java.