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)?
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
>> A call to rpc(f,a1,a2), does it generate some_child<R(T1,T2)> :
>> 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:
> 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.
> Unsubscribe & other changes: http://lists.boost.org/mailman/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk