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