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

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