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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-09 15:12:25

"William E. Kempf" <wekempf_at_[hidden]> writes:

> David Abrahams said:
>> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>>>>>     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?
>>
>> No, my fault.  Syntactically, I should've written this:
>>
>>     async_call<int> f(create_thread(), bind(g,1,2));
>>     int r = f();
>
> Do you want it to be "int r = f();" or just "int r = f;" or even "int r =
> f.result();" or similar?  

My other message makes it clear (I hope) that I want what I wrote
above.

> The f() syntax makes it look like you're invoking the call at that
> point, when in reality the call was invoked in the construction of
> f.

You're just invoking a function to get the result.  f itself is not
the result, so I don't want to use implicit conversion, and f.result()
does not let f behave polymorphically in a functional programming
context.

>>> Ouch.  A tad harsh.
>>
>> Sorry, not intended.  I was just trying to palm off responsibility for
>> justifying that line on you ;o)
>>
>>> 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.
>>
>> I don't get it.  Could you fill in more detail?  For example, where does
>> the proxy come from?
>
>>From a lot of hard work? ;)  Or often, it's generated by some IDL like
> compiler.  Traditional RPCs behave like synchronous calls, but DCOM and
> other such higher level RPC mechanisms offer you alternative designs where
> the initial invocation just wires the input to the server and you retreive
> the results (which have been asynchronously wired back to the client and
> buffered) at a later point.  In my own work we often deal with RPC
> mechanisms like this, that can take significant amounts of time to
> generate and wire the results back, and the client doesn't need/want to
> block waiting the whole time.

Sure, sure, but all the details about the proxy, etc, are missing. Not
that I think it matters... ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com