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

From: Hans Larsen (hans_at_[hidden])
Date: 2007-05-02 09:02:51

Sorry to have left the discussion so early...  I'll try to  
participate a bit more but life has been (and still is) a hell.   
There are good platforms out there (corba and dcom) that already  
performs this kind of work.  My first goal was more modest than full  
RPC support, but as I see it you've made a lot of work.

I took a look at the code you had two weeks ago, but don't know how  
it evolved since then.

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?  Both DCOM and CORBA will work  
with interfaces that are well-defined on both side to circumvent this  
case and make it work, but what would your code do in that case?  I  
suppose that actually it wouldnt get back to callee but be called on  
the same computer, which would not be desired behavior.
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?

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

Yours,
Hans

On 1-May-07, at 9:25 PM, Stjepan Rajko wrote:

> On 5/1/07, Sohail Somani <s.somani_at_[hidden]> wrote:
>>> -----Original Message-----
>>> From: boost-bounces_at_[hidden]
>>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Stjepan Rajko
>>
>>> Yes, each object passed  / returned must be serializable via
>>> Boost.Serialization.  No polymorphic interface is required from the
>>> objects.
>>
>> A call to rpc(f,a1,a2), does it generate some_child<R(T1,T2)> :  
>> public
>> some_base which is then serialized and subsequently deserialized and
>> called by some_base *?
>
> Sorry, I sent you the wrong link... oops.  The actual link is:
>
> dancinghacker.com/code/marshal/
>
> Apologies.
>
> A call rpc(f,a1,a2), to use that notation, is itself modeled roughly
> as call<R(T1,T2)> this_particular_call(f,a1,a2) which inherits
> call_base (which does provide a polymorphic interface). f (function
> identifier), a1 and a2 are all serialized within the call class, and
> after a a call rpc_client(this_particular_call) and sent over the
> network.  The syntax can be made to look like it's just a local
> function call, but the guts of it look like what I described.
>
> On the other side, a registry_server receives the packet, unserializes
> the function id, and calls a marshaled<R(T1,T2)> wrapper of the actual
> function.  The marshaled class takes care of unserializing the
> parameters and calling the actual function, then the results get
> marshaled back etc.
>
> Stjepan
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/ 
> listinfo.cgi/boost