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

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
result.
> 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
the
> > 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
be
> >> 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
this.
> >  An async_call object could take an optional thread-creation
parameter,
> > for example.
> 
> It's not "thread-creation" in this case.  You don't create threads
when
> you use a thread_pool.  And there's other examples as well, such as
RPC
> mechanisms.  And personally, I find passing such a "creation
parameter" to
> 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);
thread_pool pool;
pool.dispatch(later1);
pool.dispatch(later2);
d = later1.result() + later2.result();

> More importantly, if you really don't like the syntax of my design, it
at
> least allows you to *trivially* implement your design.  Sometimes
there's
> 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.

Regards
Darryl Green.