"William E. Kempf" <[EMAIL PROTECTED]> writes: > David Abrahams said: >> "William E. Kempf" <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
