rpc() returning a dist_object<T>

[Dan Bonachea]

Is it legal for an rpc() callback to return a dist_object<T>?

Eg:

class Mesh {public: Mesh(A, B, C); private: …};
A a; B b; C c;

    dist_object<Mesh> d1(upcxx::world(), a, b, c);
    auto fut = upcxx::rpc(0, []( dist_object<Mesh> &remote ) { 
      return remote;   // is this permitted
    }, d1);
    dist_object<Mesh> &d2 = wait(fut);
    assert(&*d1 == &*d2);

I'm not sure I have the right syntax for everything above, but the basic question is does upcxx::rpc() return value perform the dist_id conversion and when_local() interlock on arrival? If so, I'm not sure that's clearly specified.

[Former user]

Wow, never occurred to me. I think that would just work if rpc is implemented over rpc_ff each way. I don't feel comfortable guaranteeing that though. Will keep in mind.

[Former user]

Current implementation would choke on this. But its definitely doable. Should permit it.

[Amir Kamil]

Repeating my comment from the discussion for PR #2, I'm not in favor of this. I think it would require delaying operation completion until the dist_object was constructed, which complicates the semantics of operation completion. I'm not convinced the gain is worth it.

[john bachan]

Doesn't bother me a bit to drop it.

[BrianS]

There is "should this work" and I think the answer is no, a user doing this kind of rpc has not grocked the idea for a dist_object. Next question is, can we stop them at compile time from doing this with a good error message? I think the answer is yes, by disabling serialization of dist_object.

while a dist_object might be serializable, since we control the digest creation under the hood, the point of a dist_object is to lookup a remote object using your local paired dist_object

There could be a case where a user has several dist_objects made and ready for use, but only a remote rank knows which one you should be using.

future<dist_object<HashTable>> remoteTable = rpc(remote, selectorFunction);

That is pretty complicated logic.

[Amir Kamil]

dist_object is not classified as Serializable. However, rpc assumes an object is trivially serializable if it does not implement the serialization interface. So it will make a byte copy of the dist_object if it is the return value of the RPC.

It's worth considering whether we should restrict the return type of an RPC to be DefinitelySerializable, which would allows us to provide a compile-time diagnostic for this.

[Amir Kamil]

To my surprise, the text in PR #2 already states that all except the function argument to RPC must be DefinitelySerializable, as well as the return type. So we must have discussed this before and came to the same resolution.

[Dan Bonachea]

Resolved by pull request #2 in 4d0b4c44 and 640bfff - this is now prohibited, because dist_object is not DefinitelySerializable.