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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-21 20:56:02

From: Beman Dawes <bdawes_at_[hidden]>
> 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.

Right.  So is_alive() returns false, and most other calls become
no-ops or throw an exception when the thread goes away.

>  >>     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.

Yes.  And like iostreams it provides a more portable and safer interface.

> 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?

Yes please.

>     The object directly representing a thread, noncopyable semantics?

No thank you.

> 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"?

I don't much care about the name yet, but "thread" is fine by me.
Maybe thread_proxy?

A slightly more complicated interface might be the non-copyable
thread and a copyable thread_ptr with an operator->() that returns
thread*, and a counting-weak-ptr semantics that keeps the thread
object around, alive or dead, until the last thread_ptr goes away.