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)
-
-
reporter New wording in the PR looks good, thanks.
-
reporter - changed status to resolved
Fixed by merge of pull request #2 in 114ff02
- Log in to comment
New wording in PR #2: