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

From: williamkempf_at_[hidden]
Date: 2001-06-22 11:06:26

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> Bill Kempf wrote:
> 
> [ rationale for the current semantics, spread over three postings ]
> 
> OK, I'm beginning to understand the rationale now.  Let me extract 
what I 
> see as important from your messages and write it up as a Design 
Rationale 
> section for the [currently named] class thread docs.
> 
>  >I'm more interested in the interface as well, but this is the 
first
>  >anyone's commented on it ;).  The name may well be important here,
>  >however.  I understand Beman's argument and so I'm open to a name
>  >change here... but a change to thread_handle, thread_id or
>  >thread_desc, for instance, would necessitate a change to the
>  >interface as well.
> 
> Yes, I agree.  One of my problems with the current design is that 
as soon 
> as I figured out that it was a descriptor/handle/id value class, 
then the 
> statics you mention below suffered the expectation problems you 
describe.

Actually, the current design is a hybrid, which further adds to the 
confusion.  I'm swayed enough to think a redesign is needed, I'm just 
not settled on which design is "better".

>  >  Some of the static methods make sense when the
>  >class is named "thread", but not when any of these others are
>  >chosen.  The static methods sleep(), yield() and even create() and
>  >self() are not actions one would expect to take on a
>  >handle/id/descriptor to a thread, but are actions you'd expect to
>  >take on the thread itself.
> 
> Would there be a problem making them non-member functions?  To me 
that 
> sounds clearer, although I'd have to look the final interface to be 
sure.

Not necessarily, though it may complicate the implementation.  Not a 
good argument for maintaining the design, though, so...
 
>  >Another suggestion would be thread_desc or thread_descriptor.
> 
> Yes, those would work for me.  Anything except thread. Even 
thread_t would 
> be enough name distinction to me.  At least then in every email 
discussion 
> we wouldn't have to explain for every use of the word "thread" 
whether we 
> meant class thread or execution thread.

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.

Bill Kempf