Boost.Threads - name of the "thread" type

From: williamkempf_at_[hidden]
Date: 2001-06-21 14:32:46

Beman and I have been having a discussion off line on the topic of 
the name chosen for the thread class.  Here's the latest message from 
Beman to myself:

-----------

>>OK, now that I'm sure what a thread is, I have a serious problem 
with 
the 
>>name of Boost.Threads class "thread". 
>> 
>>The problem is that objects of the class represents are thread ids, 
not 
>>thread objects.  There aren't any such objects; execution 
environments 
in 
>>C++ aren't objects.  If there were, they would be noncopyable, 
among 
other 
>>things. 
>> 
>>I know this started with pthread_t, which should have been named 
>>pthread_id_t, but let's not perpetuate the mistake.  I just picked 
up 
>>Butenhof's book and it fell open to page 38, lifecycle.c.  Line 14 
of 
the 
>>listing is: 
>> 
>>     pthread_t thread_id; 
>> 
>>And Stevens book names every pthread_t argument "tid".  These 
things are 
>>thread id's, not threads. 
> 
>I can understand this view point.  However, there's historical 
precedent 
>here, and not just from pthreads.  In the Windows world MFC has it's 
>CWinThread class.  In the Java world they have their Thread class.  
Every 

>C++ thread class in every library I've ever encountered uses a 
similar 
>name. 
> 
>Their are also similar examples already in existence in the C and 
C++ 
>standards.  For example, FILE.  This is truly nothing more than 
>a descriptor 
>(which is just another form of id), while a true file is something 
quite 
>different. 

I do understand that you were following lots of precedent, but in my 
mind 
it is very poor practice to give something a name that implies 
semantics 
different from the actual semantics.  A red flag, if you will. 

It also a red flag for me when I read documentation like "Destructs a 
thread..." where changing the type font of "thread" completely 
changes the 
meaning of the sentence. 

So in my mind, either change the class name to something that denotes 
identifier, handle, or the like, or change the semantics to be more 
thread-like and less thread_id like.   Make it noncopyable, and so 
forth.  I don't entirely see how to do that.  I guess a create_thread 
static or free function could return a pointer to a thread object.  
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 the 
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'm not sure these semantics would work, and I'm certainly not 
claiming 
they would be a good idea.  Just pointing out that you may have a 
choice: 
thread id semantics or thread semantics. 

>I'm not trying to completely argue against this.  I'm willing to 
change 
the 
>name if it provides better clarity.  I'm just not convinced that it 
does, 

>given the historical precedent of naming types after the resources 
>that they manage. 
> 
>>So let's name the Boost class "thread_id" or similar. 
> 
>If we do change the name along these lines I'd prefer 
thread_handle.  The 

>term id always conjures up an integral value to me, while what we 
have is 

>really a handle, pointer or reference type concept here. 

I've personally never liked "handle"; it seems a bit Microsoft-ish, 
and the 
usage isn't quite right.  But I could live with it. 

Let me know what you think.  We can also post the question on the 
main 
list. 

--------

Any thoughts or comments on this subject from anyone else?

Bill Kempf