From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-29 22:58:38
From: John Max Skaller <skaller_at_[hidden]>
> Greg Colvin wrote:
> >
> > From: John Max Skaller <skaller_at_[hidden]>
> > > williamkempf_at_[hidden] wrote:
> > >
> > > > Considering all of the discussion so far, I think this slightly
> > > > modified interface is the best design so far:
> > > >
> > > > class thread : boost::noncopyable
> > > > {
> > >
> > > What? only one kind of thread allowed?
> > > Shouldn't this class use pure virtual methods?
> >
> > I think the answer is that this class is not intended as
> > a base class, which is one reason some of us prefer that
> > it be just a namespace.
>
> I can see that, but the question is: what happens
> if there is more than one type of thread, as on Solaris?
> Should the design be able to cope with that?
> If not, how does the vendor choose, and wouldn't clients
> be forced to roll their own if they wanted the other kind?
>
> [Perhaps I'm confused, I'm just questioning everything:
> better now than in committee, or, worse, after Standardisation:
> I really want this thing to proceed: I consider the lack
> of thread support a serious deficiency]
In the design I prefer so far you have
thread::ref thread::create(boost::function1<void>)
Some of what you might do with pure virtual methods of a thread
class can be done by whatever function object you pass in. As
for different types of thread at the OS level, I presume that
could be handled through how you configure the thread library (if
only one kind of thread is used in a given program) or through
additional arguments to create (if more than one kind of thread
can be used).