"William E. Kempf" <[EMAIL PROTECTED]> writes:
>>> 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.
...and there was much rejoicing!!
>>>> 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();
async_call<int> f(thread_pool(), bind(g,1,2));
int r = f();
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))();
^^
But you're also right about the synchronous thing. The usage isn't
very likely. More typically, you'd pass an async_call object off to
some other function, which would eventually invoke it to get the
result (potentially blocking if neccessary until the result was
available).
>>> 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?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
