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

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-05-02 23:25:59

Hi Hans,

On 5/2/07, Hans Larsen <hans_at_[hidden]> wrote:
> I took a look at the code you had two weeks ago, but don't know how
> it evolved since then.

I think since then I have implemented back-marshaling of "out"
arguments, but haven't posted the changes... The more significant
improvements are coming up with the use of futures, I'll probably
re-post when that's at a good state.

>
> What I'm curious about is this: suppose that you have a class A with
> a function member M1 (say which takes a ref to an int and change it
> for, like, system msec since Epoch).  If you have a function that
> coincidentally takes a pointer (or reference) to A and call its
> member, where is that member called?

For me, dealing with distributed objects is a whole other ball-game...
 I'm currently only dealing with remote call issues, and relying on
Boost.Serialization to send copies of objects accross the network.  If
it is sufficient for an object to be sent to the remote function, the
function then changes the object (e.g., through its member functions),
the changed object gets marshalled back and replaces the original, and
all is good, then this approach is sufficient.  If it is important
that the call is executed on the callee's computer, then this won't
cut it.

Maybe an rpc framework is not terribly useful without handling
distributed objects in the way you mention.  As it stands, I don't
plan to tackle this problem.

> Another case is exception throwing and memory allocation.  What if,
> while un-marshalling parameters on target, you're OutOfMemory? Or
> worst, on marshalling it back to origin?  That latter case may be a
> lot of problems since some side effects on target may have been done,
> and should be undone... or not?

I do plan to add exception handling - both for exceptions related to
the "remote" part (network problems, marshaling problems), and for
exceptions that happen during the call of the remote function.

> Will you restrict the case awfully to the point where the user don't
> have much choice (no exception, const pointer/reference (watch out
> for those mutable), one out, no in/out, no class passing / member
> call back, etc)?

I think the member call back might be out of the scopes for now (if
that's the scenario you're mentioning above), but the rest should be
handled.

Best,

Stjepan