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

From: Steven Kirk (steven.kirk_at_[hidden])
Date: 2001-06-22 02:56:26

Personally, I'd go for simple "thread". I'm quite willing to accept that the
thread class is not an _actual_ thread, but is in fact a _C++ abstaction of
a thread_, and as such I'm willing to accept that its semantics may be a
little different to those of an actual thread. However, a name like
thread_id or thread_handle to me suggests a c-style primitive type (e.g.
void*), and it would seem a little unnatural for me to be for such a type to
have member functions. IMHO, it makes for more sense to say "tell the thread
to sleep for 500ms", than to say "tell the thread handle to sleep for
500ms". How does a *thread handle* sleep?

> 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
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>