Boost logo

Boost :

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
>>name of Boost.Threads class "thread".
>>The problem is that objects of the class represents are thread ids,
>>thread objects. There aren't any such objects; execution
>>C++ aren't objects. If there were, they would be noncopyable,
>>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
>>Butenhof's book and it fell open to page 38, lifecycle.c. Line 14
>>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
>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.

>C++ thread class in every library I've ever encountered uses a
>Their are also similar examples already in existence in the C and
>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

I do understand that you were following lots of precedent, but in my
it is very poor practice to give something a name that implies
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.
delete of the pointer would kill the thread. But it would have to be
weak pointer because the thread might already be dead and thus the
already destroyed.

    class thread : noncopyable
        // All constructors private, so thread::create()
        // is the only way to create a thread
        ~thread(); // assert(*this != self())

        bool is_alive() const;
        void join();

        static thread * create(void (*threadfunc)(void*), void*
        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
they would be a good idea. Just pointing out that you may have a
thread id semantics or thread semantics.

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

>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


Any thoughts or comments on this subject from anyone else?

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at