Cleanup text for RPC stalling on dist_id/team_id

The text that defines target-side RPC handling for dist_id and team_id, copied from its current incarnation in pull request #2 (emphasis added):

Remote procedure calls, whether standalone (\S\ref{ch:rpc}) or completion based (\S\ref{ch:completion}), perform special handling on certain non-DefinitelySerializable \upcxx data structures. Arguments that are either a reference to \code{dist_object} type (see \S\ref{ch:distobject} Distributed Objects) or a \code{team} (see \S\ref{ch:teams} Teams) are transferred by their \code{dist_id} or \code{team_id} respectively. The recipient waits asynchronously until all of the id's have a corresponding instance constructed on the recipient. When that occurs, \code{func} is called with the recipient's instance references in place of those supplied at the send site.

The phrase "waits asynchronously" above is not defined and contradicts our own use of the term "wait" (as in future::wait()). We don't want to imply the recipient persona or its incoming RPC queue is in any way stalled by the arrival of this RPC, it's just that execution of this particular RPC is deferred until all the dependencies are satisfied.

In particular, subsequently issued RPCs targeting the same rank should probably be guaranteed to eventually be serviced at the target (given sufficient internal-level progress at the sender and user-level progress at the target master persona), despite the fact that one or more RPC's may be in a "deferred" state at the target awaiting team/dist_object construction. I believe one could construct (arguably perverse) programs that would rely upon this guarantee and deadlock otherwise.

Comments (3)