Re: [boost] Re: Boost.Threads - thread_desc concept

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 13:37:12

From: <williamkempf_at_[hidden]>
> --- 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 ;).

No correction necessary.

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

Does this mean that a detach() function must be exposed, or just
that our library has to do the right thing somehow when main()
returns?

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