E.2.3 Remote Call Interface Library Units

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.

Aspect Description for Remote_Call_Interface: Subprograms in a given package may be used in remote procedure calls.

Ramification: {AI05-0243-1} 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_items.

Reason: {8652/0078} {AI95-00048-01} Remote call interface units do not provide remote data access. A shared passive package has to be used for that. 

Reason: {AI95-00240-01} {AI95-00366-01} 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. 

Ramification: {AI05-0101-1} No anonymous access types support external streaming, so they are never allowed as parameters or results of RCI subprograms. 

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 partition. 

Aspect Description for All_Calls_Remote: All indirect or dispatching remote subprogram calls and all direct remote subprogram calls should use the Partition Communication Subsystem.

Implementation Note: {8652/0078} {AI95-00048-01} 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. 

Discussion: {8652/0078} {AI95-00048-01} {AI05-0229-1} {AI12-0031-1} When this aspect is False (or not used), it is presumed that most implementations will not make 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, etc.). 

Reason: {AI12-0031-1} There is no point to force local direct calls (including 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 partition. 

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. 

{AI95-00240-01} {AI05-0248-1} Amendment Correction: 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.

{8652/0078} {AI95-00048-01} Corrigendum: Changed the wording to allow a library subprogram to be a remote call interface unit.

{AI95-00366-01} Changed the wording to use the newly defined term type that supports external streaming, so that various issues with access types in pure units and implicitly declared attributes for type extensions are properly handled. 

{AI05-0101-1} Correction: 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. 

{AI05-0206-1} Added wording to allow private withs of preelaborated normal units in the specification of a remote call interface unit.

{AI05-0229-1} 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.

{AI05-0243-1} 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. 

{AI12-0031-1} Corrigendum: Redefined 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 partition.