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

From: williamkempf_at_[hidden]
Date: 2001-06-21 16:02:41

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

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

Bill Kempf