Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-06-27 12:32:38

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: <williamkempf_at_h...>
> > Considering all of the discussion so far, I think this slightly 
> > modified interface is the best design so far:
> > 
> >     class thread : boost::noncopyable
> >     {
> >     public:
> >         thread(detail::threadproc proc); // Starts the thread
> 
> What happens if proc throws?

I've been debating what to do here.  Currently it's undefined.  
Alternatives are 1) the thread alone dies and 2) the program aborts.  
Option 2 is probably the best, but for now I don't care about this 
specification as it doesn't effect the interface.

> Do I have to reach down into thread::detail to declare my
> proc, or will this eventually be templatatized to take any
> function or function object of zero arguments?

No, you never directly use anything from detail namespaces.  In this 
case detail::threadproc is just a typedef to boost::function1<void>.  
This already qualifies any function or function object taking zero 
arguments as valid.

> >         ~thread();  // If not detached, detaches the thread
> > 
> >         // Considering that this type is noncopyable, these
> >         // operations are probably not necessary, but I'll
> >         // leave them in for the sake of discussion.
> >         bool operator==(const thread& other) const;
> >         bool operator!=(const thread& other) const;
> > 
> >         // To allow us to not need self(), at least for
> >         // comparison.
> >         bool is_current() const;
> > 
> >         bool is_alive() const;
> > 
> >         // Waits for the thread to finish and then calls detach()
> >         void join();  
> >         // Seperates the object from the actual thread of 
execution
> >         // allowing the thread to just "evaporate" when finished
> >         // or when the main thread of execution terminates.
> >         void detach();
> > 
> >         // I have a feeling this one should go away with this
> >         // design, but again I'll leave it in for discussion.
> >         static void join_all();
> > 
> >         // These two can probably become free standing methods,
> >         // though I like the encapsulation.
> >         static void sleep(const xtime& xt);
> >         static void yield();
> >     };
> > 
> > As it stands, this design is very viable, and is the best of 
what's 
> > been discussed.  My concerns are:
> > 

[snip]

> > 6)  Should sleep() and yeild() be stand alone methods, and why?  
> > We'll need good rationale statements for this which ever route we 
> > go.  The rationale for making them static methods is to give them 
> > access to thread internals, but both current target 
implementations 
> > do not have this need, and it's possible (probable?) that no 
> > implementation will need this.
> 
> If they are standalone where do the go?

They'd go in the boost namespace.

Bill Kempf