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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-07 10:51:29

Darryl Green said:
>> -----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).

I'm not sure that binding the result and "the function" at creation time
is that helpful.  Actual results aren't that way.  This allows you to
reuse the result variable in multiple calls to different functions.  But
if people aren't comfortable with this binding scheme, I'm not opposed to
changing it.  Doing so *will* complicate things a bit, however, on the
implementation side.  So let me explore it some.

>> 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):

Dave's semantics certainly *were* different from mine (and the Futures
link posted by Alexander).  In fact, I see Alexander's post as
strengthening my argument for semantics different from Dave's.  Which
leaves us with my semantics (mostly), but some room left to argue the
syntax.

> 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();

You've not used Dave's semantics, but mine (with the variation of when you
bind).

>> 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.

The only thing that's not trivial with your syntax changes above is
dealing with the requisite reference semantics with out requiring dynamic
memory allocation.  But I think I can work around that.  If people prefer
the early/static binding, I can work on this design.  I think it's a
little less flexible, but won't argue that point if people prefer it.

-- 
William E. Kempf
wekempf_at_[hidden]