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.
> > 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk