Re: [boost] [rpc/marshal] prototype rpc / marshal library using asio and serialization (and futures in the future?)

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-04-29 15:32:20

Stjepan Rajko wrote:

>>> I can see that as being reasonable if the RPC is synchronous, but if
>> Well, not necessarily.
>>
> 
> Are you referring to the possibility that the parameter might not be
> specified as an out parameter, or do you have something else in mind?

No, my general point really is that the whole idea of 'making an RPC appear 
like a local function call' is dangerous in my view.  There are just too many 
differences between remote calls and local calls that the programmer 
ultimately needs to know about.  For example, how does the rpc endpoint 
addressed, what if the endpoint refuses connection, and (specifically related 
to synchronous behavior) how long is my process blocked while waiting for a 
response that may never come or may be delayed for several seconds because it 
takes 3 satellite hops before the result returns?  When you make a function 
call in a normal program you don't think about any of these factors.  When you 
make an RPC, you should be thinking about these things.  Similarly, network 
access is fundamentally asynchronous, so why not program it that way?

> Great thoughts... Along the lines of a thread pool, asio does provide
> the facility that would allow me to give it multiple threads as
> working threads, and it's behavior would I think match the one you
> describe - a received packet would go to an idle thread, which would
> then stay busy until the call was completed and returned.  Perhaps I
> can try going this route.

Which facility is that exactly?

Jeff