Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-08 17:12:48

"William E. Kempf" <wekempf_at_[hidden]> 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

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

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