Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk