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

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

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

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

-- 
William E. Kempf
wekempf_at_[hidden]