rpc() returning a dist_object<T>
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.
Comments (9)
-
Account Deleted -
reporter - changed component to RPC
- edited description
-
Account Deleted Current implementation would choke on this. But its definitely doable. Should permit it.
-
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.
-
Doesn't bother me a bit to drop it.
-
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 ofdist_object
.while a
dist_object
might be serializable, since we control the digest creation under the hood, the point of adist_object
is to lookup a remote object using your local paireddist_object
There could be a case where a user has several
dist_object
s 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.
-
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 thedist_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.
-
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.
-
reporter - changed status to resolved
Resolved by pull request #2 in 4d0b4c44 and 640bfff - this is now prohibited, because dist_object is not DefinitelySerializable.
- Log in to comment
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.