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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-22 12:37:39

At 12:06 PM 6/22/2001, williamkempf_at_[hidden] wrote:

 >> It may be unusual, but threads are unusually dynamic objects, and
 >> the J/Thread approach matches my intuitions.  But perhaps I have
 >> been infected by java.
 >
 >Possibly.  That's why I said it *may* be the proper compromise.  I'm
 >also imagining a thread type that was noncopyable, that spawned the
 >actual thread of execution in the constructor, and that did a join()
 >on destruction unless a detach() method had been called in between.
 >This would be more in fashion with C++ design, though it makes it at
 >least slightly more complicated to share management responsibilities
 >between various objects, which is a common task.  It also makes some
 >things difficult or impossible to do.  For instance, a self() method
 >no longer is viable or appropriate, and spawning several threads in a
 >loop becomes more complicated.

and also in a different message:

 >I'm still wondering if we shouldn't have two concepts here.  The
 >thread class would remain much as it is now, except that it would not
 >be copyable and the create() method would return a thread_desc
 >instead of a thread.  Again, this was the approach taken by J/Threads
 >and seems to be a nice compromise between the two designs being
 >discussed so far.

My intuition right from the start has been that there are two concepts, 
thread and thread_desc, and thus there should be (or at least might well 
be) two classes.   If you provide only a thread_desc, I'm sure lots of 
people will write their own threads wrapper to hide and manage the 
thread_desc.

By the way, have you considered specifying that the initial function of a 
multi-threaded program be main_thread()?  That way you could supply a 
canned   main() would could create the initial thread, making it far less 
of a special case.  For example self() returning a thread& could work even 
in main_thread() (although the complexity might be O(log n) on the number 
of running threads, instead of O(1).) Or you could make a thread& a calling 
argument to each initial function, including main_thread(), so the need for 
self would be lessened or eliminated.

Anyhow, I think you are right to review the current design in light of 
comments.  Even if you still end up with a single descriptor class rather 
than two concepts and matching classes, it will be stronger for recognizing 
that that is what it is, and tailoring the interface accordingly.

--Beman