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