Boost logo

Boost :

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

> 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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at