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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-04-29 15:53:17

On 4/29/07, Jeff Garland <jeff_at_[hidden]> wrote:
> 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?
>

I think that there are circumstances in which adopting the simplicity
of simulating a local function is worthwhile (you mentioned some in
your previous message, e.g. function calls which are quickly
evaluated, especially if the network is just a few computers sitting
next to each other connected over a local switch), and like you point
out, there are circumstances in which ignoring the reality of network
communication can be both dangerous and wasteful.  FWIW, I think both
approaches should be supported, as long as the behavior of the RPC is
well designed and documented for both the sync case and the async
case.

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

Documentation of void boost::asio::io_service::run(): 	

"Run the io_service's event processing loop.

The run() function blocks until all work has finished and there are no
more handlers to be dispatched, or until the io_service has been
interrupted.

Multiple threads may call the run() function to set up a pool of
threads from which the io_service may execute handlers.
...
"

In addition, an io_service can have a permanent work attached to it
which will keep the event processing loop active even if all of the
real communication events have been processed.

Does that sound like it would work to accomplish what you suggested?
I haven't tried it yet.

Stjepan