|
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk