From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-02-07 04:13:22
> -----Original Message-----
> From: William E. Kempf [mailto:wekempf_at_[hidden]]
> Dave Abrahams said:
> > Hm? How is the result not a result in my case?
> I didn't say it wasn't a result, I said that it wasn't "only" a
> In your case it's also the call.
Regardless of whether it invokes the function the result must always be
associated with the function at some point. It would be nice if this
could be done at creation as per Dave's suggestion but providing
behaviour like the futures alexander refers to. That is, bind the
function, its parameters and the "async_result" into a single
aync_call/future object that is a function/executable object. It can be
passed to (executed by) a thread or a thread_pool (or whatever).
> >> 2) You're still hiding the thread creation.
> > Absolutely. High-level vs. low-level.
> But I think too high-level. I say this, because it ties you solely to
> thread creation for asynchronous calls.
> >> This is a mistake to me for
> >> two reasons. First, it's not as obvious that a thread is being
> >> created here (though the new names help a lot).
> > Unimportant, IMO. Who cares how an async_call is implemented under
> > covers?
> I care, because of what comes next ;).
> >> Second, and this is more
> >> important, you've bound this concept to boost::thread explicitly.
> >> With the fully seperated concerns of my proposal, async_result can
> >> used with other asynchronous call mechanisms, such as the coming
> >> boost::thread_pool.
> > This one is important. However, there are other ways to deal with
> > An async_call object could take an optional thread-creation
> > for example.
> It's not "thread-creation" in this case. You don't create threads
> you use a thread_pool. And there's other examples as well, such as
> mechanisms. And personally, I find passing such a "creation
> be turning the design inside out.
But this doesn't (borrowing Dave's async_call syntax and Alexander's
semantics (which aren't really any different to yours):
async_call<double> later1(foo, a, b, c);
async_call<double> later2(foo, d, e, f);
d = later1.result() + later2.result();
> More importantly, if you really don't like the syntax of my design, it
> least allows you to *trivially* implement your design. Sometimes
> something to be said for being "lower level".
Well as a user I'd be *trivially* implementing something to produce the
above. Do-able I think (after I have a bit of a look at the innards of
bind), but its hardly trivial.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk