Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-27 13:17:22

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 01:08 PM 6/27/2001, Greg Colvin wrote:
>  >For the reasons Peter and I have laid out I still prefer:
>  >
>  >    namespace thread {
>  >
>  >        struct ref {
>  >
>  >           // ref is copyable, and all copies compare ==
>  >           ref(const ref& other);
>  >           ref& operator=(const ref& other);
>  >           bool operator==(const ref& other) const;
>  >           bool operator!=(const ref& other) const;
>  >
>  >           // To allow us to not need current(), at least for
>  >           // comparison.  Not needed if we have current().
>  >           bool is_current() const;
>  >
>  >           bool is_alive() const;
>  >
>  >           // Waits for the thread to finish
>  >           void join();
>  >        };
>  >
>  >        // maybe don't need this if we have ref::is_current()
>  >        ref current() const;
>  >
>  >        ref create(detail::threadproc proc); // Starts the thread
>  >
>  >        void sleep(const xtime& xt);
>  >        void yield();
>  >    };

I'll speak for him and he can correct me if wrong ;).

> What about detach()?

Not needed.  The detach() method serves no purpose when the 
underlying thread information is ref-counted.  This state information 
is simply destroyed when there are no more references (including an 
internal one maintained by the running thread).  The pthread library 
requires a detach() to clean up thread data properly since it does 
not (explicitly) use ref-counting for this state information.

That said, detach() may still be a requirement, unfortunately.  I'm 
not sure what pthreads defines the behavior as if the main thread 
terminates and there are other threads that have not yet been 
detached still running.  In fact, this issue *may* complicate the 
whole concept of ref-counting, though I suspect it's a non-issue.

> What about ~ref()?

Probably just forgotten.  It's a necessity to manage the ref-count.
 
> Was the omission of these deliberate?  (Just curious:-)

One probably was, the other probably wasn't ;).

Bill Kempf