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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-22 10:34:33

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.

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

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

--Beman