dist_object can't go out of scope

[Mathias Jacquelin]

Currently, a dist_object cannot go out of scope if one wants to use it (in RPCs for instance).

I suggest that required "internal" parts of a dist_object should be allocated on the heap, and that resource deallocation should be performed by using some specialized (inherited) version of future. I do not know if this is doable, but I would like the user to still be able to do:

future<T> foo(){
dist_object< promise<T> > myprom( std::move(promise<T>()) );
...
rpc_ff(rank, [](dist_object< promise<T> > & rprom){ rprom->fulfill_result(75); }, myprom);
...
return myprom->get_future();
}

[Dan Bonachea]

I agree we need a way for users to express this type of asynchronous pattern, without leaking memory or requiring over-synchronization.

For a practical example, see Mathias's reference implementation of broadcast.

What's the best way to express/expose this capability? Can we somehow tie the lifetime of a dist_object to a promise?

[Amir Kamil]

dist_objects have standard RAII semantics. While I have my own unrelated concerns about this (mostly having to do with destruction semantics), I don't think they're relevant here.

If you don't want to tie the lifetime of an object to a scope, then you have to take responsibility for managing its lifetime. That means allocating it on the heap, making sure you keep track of the object, and then deleting it when you're done with it. I don't see how we can get around that, whether or not dist_objects have RAII semantics.

For the specific use case here, I think attaching a callback to the future should do what you want:

future<T> foo() {
  auto myprom = new dist_object<promise<T>>(world());
  ...
  rpc_ff(rank,
         [](dist_object<promise<T>> &rprom) { rprom->fulfill_result(75); },
         *myprom);
  ...
  auto fut = (*myprom)->get_future();
  fut.then([=]() { delete myprom; });
  return fut;
}

[Dan Bonachea]

I like Amir's solution (although I think it contains a few minor typos).

[Mathias Jacquelin]

I like it as well, we can mark this as resolved