Boost logo

Boost :

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
> > identifier, handle, or the like, or change the semantics to be
> > thread-like and less thread_id like. Make it noncopyable, and
> > forth. I don't entirely see how to do that. I guess a
> > static or free function could return a pointer to a thread
> > 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
> > 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
> 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

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