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

From: williamkempf_at_[hidden]
Date: 2001-06-22 08:56:34

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:21 PM 6/21/2001, Greg Colvin wrote:
> 
>  >From: <williamkempf_at_h...>
>  >> ... 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?

I'd prefer this.  Unlike iostreams threads often need to be grouped 
and managed by other objects, which is problematic when there's no 
copying semantics.

>     The object directly representing a thread, noncopyable 
semantics?

Another argument against this design is that such an object should 
also destroy the thread, and thread cancellation is a tar baby 
waiting to pull us all into that briar bush.  Boost.Threads _may_ 
have to support cancellation at some point, but the dangers of this 
are great enough that it should be an optional part of the library, 
and destructors aren't very optional.
 
> 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"?

Another suggestion would be thread_desc or thread_descriptor.

Bill Kempf