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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-08 16:17:50

David Abrahams said:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>>
>>>> With the above AsyncCall:
>>>>
>>>> async_call<int> f( bind(g, 1, 2) ); // can offer syntactic sugar
>>>> here thread t(f); // or thread(f); for extra cuteness
>>>> int r = f.result();
>>>>
>>>> The alternative seems to be
>>>>
>>>> async_call<int> f( bind(g, 1, 2) );
>>>> int r = f.result();
>>>>
>>>> but now f is tied to boost::thread. A helper
>>>>
>>>> int r = async(g, 1, 2);
>>>
>>> Another alternative might allow all of the following:
>>>
>>>     async_call<int> f(create_thread(), bind(g,1,2));
>>>     int r = f();
>>>
>>>     async_call<int> f(thread_pool(), bind(g,1,2));
>>>     int r = f();
>>
>> Using an undefined-yet Executor concept for the first argument. This
>> is not much different from
>>
>> async_call<int> f( bind(g, 1, 2) );
>> // execute f using whatever Executor is appropriate
>> int r = f.result();
>>
>> except that the async_call doesn't need to know about Executors.
>
> ...and that you don't need a special syntax to get the result out that
> isn't compatible with functional programming.  If you want to pass a
> function object off from the above, you need something like:
>
>     bind(&async_call<int>::result, async_call<int>(bind(g, 1, 2)))

I think the light is dawning for me.  Give me a little bit of time to work
out a new design taking this into consideration.

>>>     int r = async_call<int>(create_thread(), bind(g, 1, 2));
>>>
>>>     int r = async(boost::thread(), g, 1, 2);
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>     int r = async_call<int>(rpc(some_machine), bind(g,1,2));
>>>
>>>     int r = async_call<int>(my_message_queue, bind(g,1,2));

None of these make much sense to me.  You're executing the function object
in a supposedly asynchronous manner, but the immediate assignment to int
renders it a synchronous call.  Am I missing something again?

>> All of these are possible with helper functions (and the <int> could
>> be made optional.)
>
> Yup, note the line in the middle.
>
>> I've my doubts about
>>
>>>     int r = async_call<int>(rpc(some_machine), bind(g,1,2));
>>
>> though. How do you envision this working? A local opaque function
>> object can't be RPC'ed.
>
> It would have to not be opaque ;-)
>
> Maybe it's a wrapper over Python code that can be transmitted across the
> wire.  Anyway, I agree that it's not very likely.  I just put it in
> there to satisfy Bill, who seems to have some idea how RPC can be
> squeezed into the same mold as thread invocation ;-)

Ouch.  A tad harsh.  But yes, I do see this concept applying to RPC
invocation.  "All" that's required is the proxy that handles wiring the
data and the appropriate scaffolding to turn this into an Executor. 
Obviously this is a much more strict implementation then thread
creation... you can't just call any function here.

-- 
William E. Kempf
wekempf_at_[hidden]