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

From: williamkempf_at_[hidden]
Date: 2001-06-22 13:10:29

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:06 PM 6/22/2001, williamkempf_at_h... 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.

I'll code this up as two concepts in the next few days.  Actually, 
there will be very little modification from what already exists, so 
the change is trivial, despite the major change in conceptual 
semantics.

> 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.

No, I never considered this.  For MT systems every program is going 
to have a main thread regardless of whether or not main() or a 
main_thread() is used as the program entry point.  For these systems 
it's always possible to get the "main thread" through some sort of 
self() style function any way, so all that's needed for Boost.Threads 
is a method to "adopt" the thread from such a call.  This ability is 
likely to be needed for other threads any way, so I'm not sure I see 
a lot of benefit to requiring a thread_main() entry.
 
> 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.

I'm going to wait to hear any further thoughts on this, but I expect 
I'll go to a two concept approach.

Bill Kempf