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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-06 15:18:26

Dave Abrahams said:
> On Thursday, February 06, 2003 12:33 PM [GMT+1=CET],
> William E. Kempf <wekempf_at_[hidden]> wrote:
>
>> Dave Abrahams said:
>>
>> > > Hmm... that would be
>> > > an interesting alternative implementation.  I'm not sure it's as
>> "obvious" as the syntax I suggested
>> >
>> > Sorry, IMO there's nothing "obvious" about your syntax.  It looks
>> cumbersome and low-level to me.  Let me suggest some other syntaxes
>> for async_result, though:
>> >
>> >     async_call<double> later(foo, a, b, c)
>> >
>> > or, if you don't want to duplicate the multi-arg treatment of
>> bind(), just:
>> >
>> >     async_call<double> later(bind(foo, a, b, c));
>> >     ...
>> >     ...
>> >     double d = later(); // call it to get the result out.
>>
>> The two things that come to mind for me with this suggestion are:
>>
>> 1) You've explicitly tied the result into the call.  I chose the other
>> design because the result is just that, only a result.
>
> 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.

>> An asynchronous call can be bound to this result more than once.
>
> ...and if it can't be default-constructed?

That's what boost::optional<> is for ;).

>> 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.
>>
>>    asyc_result<double> res1, res2;
>>    thread_pool pool;
>>    pool.dispatch(bind(res1.call(foo), a, b, c));
>>    pool.dispatch(bind(res2.call(foo), d, e, f));
>>    d = res1.value() + res2.value();
>
> 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.  It might make things a little simpler
for the default case, but it complicates usage for all the other cases. 
With the design I presented every usage is treated the same.

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

>> > That's what we mean by the terms "high-level" and "encapsulation"
>> ;-)
>>
>> Yes, but encapsulation shouldn't hide the implementation to the point
>> that users aren't aware of what the operations actually are. ;)
>
> I don't think I agree with you, if you mean that the implementation
> should be apparent from looking at the usage.  Implementation details
> that must be revealed should be shown in the documentation.

I was referring to the fact that you have no idea if the "async call" is
being done via a thread, a thread_pool, an RPC mechanism, a simple message
queue, etc.  Sometimes you don't care, but often you do.

-- 
William E. Kempf
wekempf_at_[hidden]