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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-21 20:29:58

At 04:21 PM 6/21/2001, Greg Colvin wrote:

 >From: <williamkempf_at_[hidden]>
 >> ... Beman sugggests ...
 >> 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 understand noncopyable, but why force heap allocation via the
 >create call?

Because I just picked up Bill's id semantics interface, and hacked it for a 
minute or two.  As soon as I sent it I realized there was no obvious need 
for forcing heap allocation.  A more usual constructor would be better, at 
least for discussion's sake.

Back to the main discussion.  It seems to me that a thread is similar to an 
fstream in that it represents a resource object which actually is owned by 
the operating system.

Now iostreams could have done a C-like fstream interface which was really 
just a holder for a file id or handle.  The fstreams would be small value 
types that were typically passed by value, could be freely copied with no 
effect what so ever on the underlying file, and so forth.

Of iostreams could have (and did) try to make an fstream object look and 
act as much as possible as if it were in fact a file object itself, not an 
id, handle, pointer, or other link to the real thing.

Now substitute "thread" in the above.

Which would people prefer, and why?

    The id/handle/pointer/link copyable semantics?

    The object directly representing a thread, noncopyable semantics?

If you like the id/handle/pointer/link semantics, would you still like to 
see the class called "thread" rather than "thread_id" or "thread_handle" or 
"thread_pointer" or "thread_link"?

--Beman