Re: [boost] Re: A new boost::thread implementation?

From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-06 10:38:04

From: "Wolfgang Bangerth" <bangerth_at_[hidden]>

> > >     double d;
> > >     thread<double> t = spawn(foo)(a,b,c);
> > >     // do something else
> > >     d = thread.return_value();
> >
> > A solution like this has been proposed before, but I don't like it.
This
> > creates multiple thread types, instead of a single thread type.  I think
> > this will only make the interface less convenient, and will make the
> > implementation much more complex.  For instance, you now must have a
> > seperate thread_self type that duplicates all of thread<> except for the
> > data type specific features.  These differing types will have to compare
> > to each other, however.
>
> Make the common part a base class. That's how the proposal I sent you does
> it :-)
>
>
> > async_result<double> res;
> > thread t(bind(res.call(), a, b, c));
> > // do something else
> > d = res.value();  // Explicitly waits for the thread to return a value?
>
> This does the same, indeed. Starting a thread this way is just a little
> more complex (and -- in my view -- less obvious to read) than writing
>   thread t = spawn(foo)(a,b,c);
>
> But that's just personal opinion, and I'm arguably biased :-)

I'm sure I'm never biased <wink>, and I tend to like your syntax better.
However, I recognize what Bill is concerned about.  Let me suggest a
compromise:

  async_result<double> later = spawn(foo)(a, b, c);
  ...
  thread& t = later.thread();
  // do whatever with t
  ...
  double now = later.join();  // or later.get()

You could also consider the merits of providing an implicit conversion from
async_result<T> to T.

This approach doesn't get the asynchronous call wound up with the meaning of
the "thread" concept.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com