Boost logo

Boost :

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?
> > > 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
> > (to use terminology more familiar to most folks here). Thread
> > cancellation is a slippery slope in C++ for reasons beyond just
> > 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
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at