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

From: williamkempf_at_[hidden]
Date: 2001-06-21 16:51:15

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > > From: <williamkempf_at_h...>
> > > 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.

In general this isn't a common need.  Why must a group of threads be 
started at the same (or nearly same) time?  If they are properly 
parallel processes they shouldn't have a need for this.  If you 
really have a need for this it would be nearly as easy to explicitly 
code for it using a condition variable instead of having this 
functionality built into the library.
 
> > > 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.

The crux of it is that a "thread" is an execution state, which 
obviously can't be copied.  The thread _class_, however, is nothing 
more than an id, handle, pointer, reference or some other concept 
associated with the actual thread.  Beman thinks this makes the name 
a poor choice.  (Beman, feel free to explain this better than I just 
did... with out the full off line thread I'm sure I've left something 
important out for others to grasp your argument properly.)
 
> > > 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.

I'm open to this, but I don't have the experience or knowledge to 
address it.  I'll have to leave this up to others to handle.

Bill Kempf