E.2.3 Remote Call Interface Library Units
[A remote call interface library unit can be used
as an interface for remote procedure calls (RPCs) (or remote function
calls) between active partitions.]
Language Design Principles
The restrictions governing a remote call interface
library unit are intended to ensure that the values of the actual parameters
in a remote call can be meaningfully sent between two active partitions.
form of a pragma
Remote_Call_Interface is as follows:
The form of a pragma
All_Calls_Remote is as follows:
All_Calls_Remote is a library unit pragma.
is used to specify that a library unit is a remote call interface
, namely that the Remote_Call_Interface aspect
of the library unit is True. A subprogram declared in the visible part
of such a library unit, or declared by such a library unit, is called
a remote subprogram
Aspect Description for Remote_Call_Interface:
Subprograms in a given package may be used in remote procedure calls.
The declaration of an RCI library unit shall be preelaborable (see 10.2.1
and shall depend semantically only upon declared pure library_item
shared passive library units, remote types library units, other remote
call interface library units, or preelaborated normal library units that
are mentioned only in private with clauses.
We say declared pure library_item
here, so that (all) limited views are allowed; those are not library
units, but they are declared pure library_item
Remote call interface units do not provide remote data access. A shared
passive package has to be used for that.
We disallow the declaration of task and protected types, since calling
an entry or a protected subprogram implicitly passes an object of a limited
type (the target task or protected object). We disallow other limited
types since we require that such types have available Read and Write
attributes, but we certainly don't want the Read and Write attributes
themselves to involve remote calls (thereby defeating their purpose of
marshalling the value for remote calls).
Reason: This is disallowed because the
body of the nested generic would presumably have access to data inside
the body of the RCI package, and if instantiated in a different partition,
remote data access might result, which is not supported.
No anonymous access types support external streaming, so they are never
allowed as parameters or results of RCI subprograms.
any public child of the library unit shall be a
remote call interface library unit.
Reason: No restrictions apply to the
private part of an RCI package, and since a public child can “see”
the private part of its parent, such a child must itself have a Remote_Call_Interface
pragma, and be assigned to the same partition (see below).
Discussion: We considered making the
public child of an RCI package implicitly RCI, but it seemed better to
require an explicit pragma to avoid any confusion.
Note that there is no need for a private child
to be an RCI package, since it can only be seen from the body of its
parent or its siblings, all of which are required to be in the same active
A pragma All_Calls_Remote sets the All_Calls_Remote representation aspect
the library unit to which
the pragma applies to the value True. If the All_Calls_Remote aspect
of a library unit is True, the library unit shall be a remote call interface.
Aspect Description for All_Calls_Remote:
All indirect or dispatching remote subprogram
calls and all direct remote subprogram procedure
calls should use the Partition Communication Subsystem,
even if they are local.
A remote call interface library unit shall be assigned
to at most one partition of a given program. A remote call interface
library unit whose parent is also an RCI library unit shall be assigned
only to the same partition as its parent.
The declaration of an RCI unit, with a calling-stub body, is automatically
included in all active partitions with compilation units that depend
on it. However the whole RCI library unit, including its (non-stub) body,
will only be in one of the active partitions.
the rule given in 10.2
, a compilation unit
in a given partition that semantically depends on the declaration of
an RCI library unit, needs
(in the sense of 10.2
only the declaration of the RCI library unit, not the body, to be included
in that same partition. [Therefore, the body of an RCI library unit is
included only in the partition to which the RCI library unit is explicitly
If aspect All_Calls_Remote is True for a
given RCI library unit, then the implementation shall route any of
the following calls call to a subprogram
of the RCI unit from outside the declarative region of the unit
through the Partition Communication Subsystem (PCS); see E.5:.
Calls to such subprograms from within the declarative region of the unit
are defined to be local and shall not go through the PCS.
A direct call to a subprogram of the RCI unit from
outside the declarative region of the unit;
An indirect call through a remote access-to-subprogram
value that designates a subprogram of the RCI unit;
A dispatching call with a controlling operand designated
by a remote access-to-class-wide value whose tag identifies a type declared
in the RCI unit.
When this aspect is False (or not used), it is presumed that most implementations
calls through the PCS
if the call originates
in the same partition as that of the RCI unit. When this aspect is True,
all indirect or dispatching remote subprogram calls
to the RCI unit and all direct
calls from outside the subsystem
rooted at the RCI unit are treated like calls from outside the partition,
ensuring that the PCS is involved in all such calls (for debugging, redundancy,
There is no point to force local direct
calls from children) to go through the PCS, since on the target system,
these calls are always local, and all the units are in the same active
An implementation need not support the Remote_Call_Interface pragma or
aspect nor the All_Calls_Remote pragma. [Explicit message-based communication
between active partitions can be supported as an alternative to RPC.]
Ramification: Of course, it is pointless
to support the All_Calls_Remote pragma if the Remote_Call_Interface pragma
(or some approximate equivalent) is not supported.
Incompatibilities With Ada 95
The wording was changed
from “user-specified” to “available” read and
write attributes. (This was then further changed, see below.) This means
that a type with the attributes specified in the private part would originally
have been allowed as a formal parameter of an RCI subprogram, but that
is no longer allowed. This change was made so that the rules were consistent
with the rules introduced for the Corrigendum for stream attributes;
moreover, legality should not depend on the contents of the private part.
Wording Changes from Ada 95
Changed the wording to allow a library subprogram
to be a remote call interface unit.
Changed the wording to use the newly defined term type that supports
, so that various issues with access types in pure
units and implicitly declared attributes for type extensions are properly
Incompatibilities With Ada 2005
Added a rule to ensure that function
results are streamable; this was missing in previous versions of Ada.
While programs that returned unstreamable types from RCI functions were
legal, it is not clear what they could have done (as the results could
not be marshalled). Thus, it seems unlikely that any real programs will
be impacted by this change.
Extensions to Ada 2005
Added wording to allow private withs of preelaborated
normal units in the specification of a remote call interface unit.
All_Calls_Remote is now a representation aspect, so it can be specified
by an aspect_specification
— although the pragma is still preferred by the Standard.
Remote_Call_Interface is now a categorization aspect, so it can be specified
by an aspect_specification
— although the pragma is still preferred by the Standard.
Inconsistencies With Ada 2012
when indirect and dispatching remote calls have to be remote for a unit
for which the aspect All_Calls_Remote is True. With the new rules, a
local target called indirectly or via dispatching will be routed through
the PCS, while that was not necessarily true in earlier Ada. If a program
depended on local targets not being routed through the PCS even when
All_Calls_Remote is used, then it might behave differently or fail in
corrected Ada 2012. This is highly unlikely as PCS is going to be able
to communicate with any partition of the program, including the local
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe