Go to the first, previous, next, last section, table of contents.

Distributed Systems (normative)

This Annex defines facilities for supporting the implementation of distributed systems using multiple partitions working cooperatively as part of a single Ada program. Post-Compilation Rules
A distributed system is an interconnection of one or more processing nodes (a system resource that has both computational and storage capabilities), and zero or more storage nodes (a system resource that has only storage capabilities, with the storage addressable by one or more processing nodes).
A distributed program comprises one or more partitions that execute independently (except when they communicate) in a distributed system.
The process of mapping the partitions of a program to the nodes in a distributed system is called configuring the partitions of the program. Implementation Requirements
The implementation shall provide means for explicitly assigning library units to a partition and for the configuring and execution of a program consisting of multiple partitions on a distributed system; the means are implementation defined. Implementation Permissions
An implementation may require that the set of processing nodes of a distributed system be homogeneous. NOTES
(1) The partitions comprising a program may be executed on differently configured distributed systems or on a non-distributed system without requiring recompilation. A distributed program may be partitioned differently from the same set of library units without recompilation. The resulting execution is semantically equivalent.
(2) A distributed program retains the same type safety as the equivalent single partition program.

Partitions

The partitions of a distributed program are classified as either active or passive. Post-Compilation Rules
An active partition is a partition as defined in section Program Execution. A passive partition is a partition that has no thread of control of its own, whose library units are all preelaborated, and whose data and subprograms are accessible to one or more active partitions.
A passive partition shall include only library_items that either are declared pure or are shared passive, see section Elaboration Control, and section Shared Passive Library Units.
An active partition shall be configured on a processing node. A passive partition shall be configured either on a storage node or on a processing node.
The configuration of the partitions of a program onto a distributed system shall be consistent with the possibility for data references or calls between the partitions implied by their semantic dependences. Any reference to data or call of a subprogram across partitions is called a remote access. Dynamic Semantics
A library_item is elaborated as part of the elaboration of each partition that includes it. If a normal library unit, see section Categorization of Library Units, has state, then a separate copy of the state exists in each active partition that elaborates it. The state evolves independently in each such partition.
An active partition terminates when its environment task terminates. A partition becomes inaccessible if it terminates or if it is aborted. An active partition is aborted when its environment task is aborted. In addition, if a partition fails during its elaboration, it becomes inaccessible to other partitions. Other implementation-defined events can also result in a partition becoming inaccessible.
For a prefix D that denotes a library-level declaration, excepting a declaration of or within a declared-pure library unit, the following attribute is defined:

D'Partition_ID

Denotes a value of the type universal_integer that
identifies the partition in which D was elaborated. If D
denotes the declaration of a remote call interface
library unit, see section Remote Call Interface Library Units, the given partition is the
one where the body of D was elaborated.

Bounded (Run-Time) Errors

It is a bounded error for there to be cyclic elaboration dependences between the active partitions of a single distributed program. The possible effects are deadlock during elaboration, or the raising of Program_Error in one or all of the active partitions involved. Implementation Permissions
An implementation may allow multiple active or passive partitions to be configured on a single processing node, and multiple passive partitions to be configured on a single storage node. In these cases, the scheduling policies, treatment of priorities, and management of shared resources between these partitions are implementation defined.
An implementation may allow separate copies of an active partition to be configured on different processing nodes, and to provide appropriate interactions between the copies to present a consistent state of the partition to other active partitions.
In an implementation, the partitions of a distributed program need not be loaded and elaborated all at the same time; they may be loaded and elaborated one at a time over an extended period of time. An implementation may provide facilities to abort and reload a partition during the execution of a distributed program.
An implementation may allow the state of some of the partitions of a distributed program to persist while other partitions of the program terminate and are later reinvoked. NOTES
(3) Library units are grouped into partitions after compile time, but before run time. At compile time, only the relevant library unit properties are identified using categorization pragmas.
(4) The value returned by the Partition_ID attribute can be used as a parameter to implementation-provided subprograms in order to query information about the partition.

Categorization of Library Units

Library units can be categorized according to the role they play in a distributed program. Certain restrictions are associated with each category to ensure that the semantics of a distributed program remain close to the semantics for a nondistributed program.
A categorization pragma is a library unit pragma, see section Pragmas and Program Units, that restricts the declarations, child units, or semantic dependences of the library unit to which it applies. A categorized library unit is a library unit to which a categorization pragma applies.
The pragmas Shared_Passive, Remote_Types, and Remote_Call_Interface are categorization pragmas. In addition, for the purposes of this Annex, the pragma Pure, see section Elaboration Control is considered a categorization pragma.
A library package or generic library package is called a shared passive library unit if a Shared_Passive pragma applies to it. A library package or generic library package is called a remote types library unit if a Remote_Types pragma applies to it. A library package or generic library package is called a remote call interface if a Remote_Call_Interface pragma applies to it. A normal library unit is one to which no categorization pragma applies.
The various categories of library units and the associated restrictions are described in this clause and its subclauses. The categories are related hierarchically in that the library units of one category can depend semantically only on library units of that category or an earlier one, except that the body of a remote types or remote call interface library unit is unrestricted.
The overall hierarchy (including declared pure) is as follows:

Declared Pure

Can depend only on other declared pure library units;

Shared Passive

Can depend only on other shared passive or declared pure
library units;

Remote Types

The declaration of the library unit can depend only on other
remote types library units, or one of the above; the body of
the library unit is unrestricted;

Remote Call Interface

The declaration of the library unit can depend only on other
remote call interfaces, or one of the above; the body of the
library unit is unrestricted;

Normal
```
Unrestricted.
```
Declared pure and shared passive library units are preelaborated. The declaration of a remote types or remote call interface library unit is required to be preelaborable. Implementation Requirements
For a given library-level type declared in a preelaborated library unit or in the declaration of a remote types or remote call interface library unit, the implementation shall choose the same representation for the type upon each elaboration of the type's declaration for different partitions of the same program. Implementation Permissions
Implementations are allowed to define other categorization pragmas.

Shared Passive Library Units

A shared passive library unit is used for managing global data shared between active partitions. The restrictions on shared passive library units prevent the data or tasks of one active partition from being accessible to another active partition through references implicit in objects declared in the shared passive library unit. Syntax
The form of a pragma Shared_Passive is as follows:

pragma Shared_Passive[(library_unit_name)];

Legality Rules

A shared passive library unit is a library unit to which a Shared_Passive pragma applies. The following restrictions apply to such a library unit:
1. it shall be preelaborable, see section Elaboration Control,
2. it shall depend semantically only upon declared pure or shared passive library units;
3. it shall not contain a library-level declaration of an access type that designates a class-wide type, task type, or protected type with entry_declarations; if the shared passive library unit is generic, it shall not contain a declaration for such an access type unless the declaration is nested within a body other than a package_body.

Notwithstanding the definition of accessibility given in section Operations of Access Types, the declaration of a library unit P1 is not accessible from within the declarative region of a shared passive library unit P2, unless the shared passive library unit P2 depends semantically on P1. Static Semantics
A shared passive library unit is preelaborated. Compilation Rules
A shared passive library unit shall be assigned to at most one partition within a given program.
Notwithstanding the rule given in section Program Execution, a compilation unit in a given partition does not need (in the sense of See section Program Execution.) the shared passive library units on which it depends semantically to be included in that same partition; they will typically reside in separate passive partitions.

Remote Types Library Units

A remote types library unit supports the definition of types intended for use in communication between active partitions. Syntax
The form of a pragma Remote_Types is as follows:

pragma Remote_Types[(library_unit_name)];

Legality Rules

A remote types library unit is a library unit to which the pragma Remote_Types applies. The following restrictions apply to the declaration of such a library unit:
1. it shall be preelaborable;
2. it shall depend semantically only on declared pure, shared passive, or other remote types library units;
3. it shall not contain the declaration of any variable within the visible part of the library unit;
4. if the full view of a type declared in the visible part of the library unit has a part that is of a non-remote access type, then that access type, or the type of some part that includes the access type subcomponent, shall have user-specified Read and Write attributes.

An access type declared in the visible part of a remote types or remote call interface library unit is called a remote access type. Such a type shall be either an access-to-subprogram type or a general access type that designates a class-wide limited private type.
The following restrictions apply to the use of a remote access-to-subprogram type:
1. A value of a remote access-to-subprogram type shall be converted only to another (subtype-conformant) remote access-to-subprogram type;
2. The prefix of an Access attribute_reference that yields a value of a remote access-to-subprogram type shall statically denote a (subtype-conformant) remote subprogram.

The following restrictions apply to the use of a remote access-to-class-wide type:
1. The primitive subprograms of the corresponding specific limited private type shall only have access parameters if they are controlling formal parameters; the types of all the non-controlling formal parameters shall have Read and Write attributes.
2. A value of a remote access-to-class-wide type shall be explicitly converted only to another remote access-to-class-wide type;
3. A value of a remote access-to-class-wide type shall be dereferenced (or implicitly converted to an anonymous access type) only as part of a dispatching call where the value designates a controlling operand of the call, see section Remote Subprogram Calls,
4. The Storage_Pool and Storage_Size attributes are not defined for remote access-to-class-wide types; the expected type for an allocator shall not be a remote access-to-class-wide type; a remote access-to-class-wide type shall not be an actual parameter for a generic formal access type;

(5) A remote types library unit need not be pure, and the types it defines may include levels of indirection implemented by using access types. User-specified Read and Write attributes, see section Stream-Oriented Attributes provide for sending values of such a type between active partitions, with Write marshalling the representation, and Read unmarshalling any levels of indirection.

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. Syntax
The form of a pragma Remote_Call_Interface is as follows:

pragma Remote_Call_Interface[(library_unit_name)];

The form of a pragma All_Calls_Remote is as follows:
```
pragma All_Calls_Remote[(library_unit_name)];
```
1. A pragma All_Calls_Remote is a library unit pragma.

Legality Rules

A remote call interface (RCI) is a library unit to which the pragma Remote_Call_Interface applies. A subprogram declared in the visible part of such a library unit is called a remote subprogram.
The declaration of an RCI library unit shall be preelaborable, See section Elaboration Control, and shall depend semantically only upon declared pure, shared passive, remote types, or other remote call interface library units.
In addition, the following restrictions apply to the visible part of an RCI library unit:
1. it shall not contain the declaration of a variable;
2. it shall not contain the declaration of a limited type;
3. it shall not contain a nested generic_declaration;
4. it shall not contain the declaration of a subprogram to which a pragma Inline applies;
5. it shall not contain a subprogram (or access-to-subprogram) declaration whose profile has an access parameter, or a formal parameter of a limited type unless that limited type has user-specified Read and Write attributes;
6. any public child of the library unit shall be a remote call interface library unit.

If a pragma All_Calls_Remote applies to a library unit, the library unit shall be a remote call interface. Post-Compilation Rules
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.
Notwithstanding the rule given in section Program Execution, a compilation unit in a given partition that semantically depends on the declaration of an RCI library unit, needs (in the sense of See section Program Execution.) 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 assigned. Implementation Requirements
If a pragma All_Calls_Remote applies to a given RCI library package, then the implementation shall route any call to a subprogram of the RCI package from outside the declarative region of the package through the Partition Communication Subsystem (PCS); See section Partition Communication Subsystem. Calls to such subprograms from within the declarative region of the package are defined to be local and shall not go through the PCS. Implementation Permissions
An implementation need not support the Remote_Call_Interface pragma nor the All_Calls_Remote pragma. Explicit message-based communication between active partitions can be supported as an alternative to RPC.

Consistency of a Distributed System

This clause defines attributes and rules associated with verifying the consistency of a distributed program. Static Semantics
For a prefix P that statically denotes a program unit, the following attributes are defined:

P'Version

Yields a value of the predefined type String that identifies
the version of the compilation unit that contains the
declaration of the program unit.

P'Body_Version

Yields a value of the predefined type String that identifies
the version of the compilation unit that contains the body
(but not any subunits) of the program unit.

The version of a compilation unit changes whenever the version changes for any compilation unit on which it depends semantically. The version also changes whenever the compilation unit itself changes in a semantically significant way. It is implementation defined whether there are other events (such as recompilation) that result in the version of a compilation unit changing. Bounded (Run-Time) Errors
In a distributed program, a library unit is consistent if the same version of its declaration is used throughout. It is a bounded error to elaborate a partition of a distributed program that contains a compilation unit that depends on a different version of the declaration of a shared passive or RCI library unit than that included in the partition to which the shared passive or RCI library unit was assigned. As a result of this error, Program_Error can be raised in one or both partitions during elaboration; in any case, the partitions become inaccessible to one another.

Remote Subprogram Calls

A remote subprogram call is a subprogram call that invokes the execution of a subprogram in another partition. The partition that originates the remote subprogram call is the calling partition, and the partition that executes the corresponding subprogram body is the called partition. Some remote procedure calls are allowed to return prior to the completion of subprogram execution. These are called asynchronous remote procedure calls.
There are three different ways of performing a remote subprogram call:
1. As a direct call on a (remote) subprogram explicitly declared in a remote call interface;
2. As an indirect call through a value of a remote access-to-subprogram type;
3. As a dispatching call with a controlling operand designated by a value of a remote access-to-class-wide type.

The first way of calling corresponds to a static binding between the calling and the called partition. The latter two ways correspond to a dynamic binding between the calling and the called partition.
A remote call interface library unit, see section Remote Call Interface Library Units, defines the remote subprograms or remote access types used for remote subprogram calls. Legality Rules
In a dispatching call with two or more controlling operands, if one controlling operand is designated by a value of a remote access-to-class-wide type, then all shall be. Dynamic Semantics
For the execution of a remote subprogram call, subprogram parameters (and later the results, if any) are passed using a stream-oriented representation, see section The Package Streams, which is suitable for transmission between partitions. This action is called marshalling. Unmarshalling is the reverse action of reconstructing the parameters or results from the stream-oriented representation. Marshalling is performed initially as part of the remote subprogram call in the calling partition; unmarshalling is done in the called partition. After the remote subprogram completes, marshalling is performed in the called partition, and finally unmarshalling is done in the calling partition.
A calling stub is the sequence of code that replaces the subprogram body of a remotely called subprogram in the calling partition. A receiving stub is the sequence of code (the "wrapper") that receives a remote subprogram call on the called partition and invokes the appropriate subprogram body.
Remote subprogram calls are executed at most once, that is, if the subprogram call returns normally, then the called subprogram's body was executed exactly once.
The task executing a remote subprogram call blocks until the subprogram in the called partition returns, unless the call is asynchronous. For an asynchronous remote procedure call, the calling task can become ready before the procedure in the called partition returns.
If a construct containing a remote call is aborted, the remote subprogram call is cancelled. Whether the execution of the remote subprogram is immediately aborted as a result of the cancellation is implementation defined.
If a remote subprogram call is received by a called partition before the partition has completed its elaboration, the call is kept pending until the called partition completes its elaboration (unless the call is cancelled by the calling partition prior to that).
If an exception is propagated by a remotely called subprogram, and the call is not an asynchronous call, the corresponding exception is reraised at the point of the remote subprogram call. For an asynchronous call, if the remote procedure call returns prior to the completion of the remotely called subprogram, any exception is lost.
The exception Communication_Error, see section Partition Communication Subsystem is raised if a remote call cannot be completed due to difficulties in communicating with the called partition.
All forms of remote subprogram calls are potentially blocking operations, see section Protected Subprograms and Protected Actions.
In a remote subprogram call with a formal parameter of a class-wide type, a check is made that the tag of the actual parameter identifies a tagged type declared in a declared-pure or shared passive library unit, or in the visible part of a remote types or remote call interface library unit. Program_Error is raised if this check fails.
In a dispatching call with two or more controlling operands that are designated by values of a remote access-to-class-wide type, a check is made (in addition to the normal Tag_Check -- see section Suppressing Checks.) that all the remote access-to-class-wide values originated from Access attribute_references that were evaluated by tasks of the same active partition. Constraint_Error is raised if this check fails. Implementation Requirements
The implementation of remote subprogram calls shall conform to the PCS interface as defined by the specification of the language-defined package System.RPC, see section Partition Communication Subsystem. The calling stub shall use the Do_RPC procedure unless the remote procedure call is asynchronous in which case Do_APC shall be used. On the receiving side, the corresponding receiving stub shall be invoked by the RPC-receiver. NOTES
(6) A given active partition can both make and receive remote subprogram calls. Thus, an active partition can act as both a client and a server.
(7) If a given exception is propagated by a remote subprogram call, but the exception does not exist in the calling partition, the exception can be handled by an others choice or be propagated to and handled by a third partition.

Pragma Asynchronous

This subclause introduces the pragma Asynchronous which allows a remote subprogram call to return prior to completion of the execution of the corresponding remote subprogram body. Syntax
The form of a pragma Asynchronous is as follows:
```
pragma Asynchronous(local_name);
```
Legality Rules
The local_name of a pragma Asynchronous shall denote either:
1. One or more remote procedures; the formal parameters of the procedure(s) shall all be of mode in;
2. The first subtype of a remote access-to-procedure type; the formal parameters of the designated profile of the type shall all be of mode in;
3. The first subtype of a remote access-to-class-wide type.

Static Semantics

A pragma Asynchronous is a representation pragma. When applied to a type, it specifies the type-related asynchronous aspect of the type. Dynamic Semantics
A remote call is asynchronous if it is a call to a procedure, or a call through a value of an access-to-procedure type, to which a pragma Asynchronous applies. In addition, if a pragma Asynchronous applies to a remote access-to-class-wide type, then a dispatching call on a procedure with a controlling operand designated by a value of the type is asynchronous if the formal parameters of the procedure are all of mode in. Implementation Requirements
Asynchronous remote procedure calls shall be implemented such that the corresponding body executes at most once as a result of the call.

Example of Use of a Remote Access-to-Class-Wide Type

Examples

Example of using a remote access-to-class-wide type to achieve dynamic binding across active partitions:

package Tapes is
   pragma Pure(Tapes);
   type Tape is abstract tagged limited private;
   -- Primitive dispatching operations where
   -- Tape is controlling operand
   procedure Copy (From, To : access Tape;
                   Num_Recs : in Natural) is abstract;
   procedure Rewind (T : access Tape) is abstract;
   -- More operations
private
   type Tape is ...
end Tapes;

with Tapes;
package Name_Server is
   pragma Remote_Call_Interface;
   -- Dynamic binding to remote operations is achieved
   -- using the access-to-limited-class-wide type Tape_Ptr
   type Tape_Ptr is access all Tapes.Tape'Class;
   -- The following statically bound remote operations
   -- allow for a name-server capability in this example
   function  Find     (Name : String) return Tape_Ptr;
   procedure Register (Name : in String; T : in Tape_Ptr);
   procedure Remove   (T : in Tape_Ptr);
   -- More operations
end Name_Server;

package Tape_Driver is
  -- Declarations are not shown, they are irrelevant here
end Tape_Driver;

with Tapes, Name_Server;
package body Tape_Driver is
   type New_Tape is new Tapes.Tape with ...
   procedure Copy
    (From, To : access New_Tape; Num_Recs: in Natural) is
   begin
     . . .
   end Copy;
   procedure Rewind (T : access New_Tape) is
   begin
      . . .
   end Rewind;
   -- Objects remotely accessible through use
   -- of Name_Server operations
   Tape1, Tape2 : aliased New_Tape;
begin
   Name_Server.Register ("NINE-TRACK",  Tape1'Access);
   Name_Server.Register ("SEVEN-TRACK", Tape2'Access);
end Tape_Driver;

with Tapes, Name_Server;
-- Tape_Driver is not needed
-- and thus not mentioned in the with_clause
procedure Tape_Client is
   T1, T2 : Name_Server.Tape_Ptr;
begin
   T1 := Name_Server.Find ("NINE-TRACK");
   T2 := Name_Server.Find ("SEVEN-TRACK");
   Tapes.Rewind (T1);
   Tapes.Rewind (T2);
   Tapes.Copy (T1, T2, 3);
end Tape_Client;

Notes on the example:
1. The package Tapes provides the necessary declarations of the type and its primitive operations.
2. Name_Server is a remote call interface package and is elaborated in a separate active partition to provide the necessary naming services (such as Register and Find) to the entire distributed program through remote subprogram calls.
3. Tape_Driver is a normal package that is elaborated in a partition configured on the processing node that is connected to the tape device(s). The abstract operations are overridden to support the locally declared tape devices (Tape1, Tape2). The package is not visible to its clients, but it exports the tape devices (as remote objects) through the services of the Name_Server. This allows for tape devices to be dynamically added, removed or replaced without requiring the modification of the clients' code.
4. The Tape_Client procedure references only declarations in the Tapes and Name_Server packages. Before using a tape for the first time, it needs to query the Name_Server for a system-wide identity for that tape. From then on, it can use that identity to access the tape device.
5. Values of remote access type Tape_Ptr include the necessary information to complete the remote dispatching operations that result from dereferencing the controlling operands T1 and T2.

Partition Communication Subsystem

The Partition Communication Subsystem (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS. An implementation conforming to this Annex shall use the RPC interface to implement remote subprogram calls. Static Semantics
The following language-defined library package exists:

with Ada.Streams; --  see section The Package Streams.
package System.RPC is

   type Partition_ID is range 0 .. implementation-defined;

```
   Communication_Error : exception;
```

   type Params_Stream_Type(
      Initial_Size : Ada.Streams.Stream_Element_Count) is new
      Ada.Streams.Root_Stream_Type with private;

   procedure Read(
      Stream : in out Params_Stream_Type;
      Item : out Ada.Streams.Stream_Element_Array;
      Last : out Ada.Streams.Stream_Element_Offset);

   procedure Write(
      Stream : in out Params_Stream_Type;
      Item : in Ada.Streams.Stream_Element_Array);

   -- Synchronous call
   procedure Do_RPC(
      Partition  : in Partition_ID;
      Params     : access Params_Stream_Type;
      Result     : access Params_Stream_Type);

   -- Asynchronous call
   procedure Do_APC(
      Partition  : in Partition_ID;
      Params     : access Params_Stream_Type);

   -- The handler for incoming RPCs
   type RPC_Receiver is access procedure(
      Params     : access Params_Stream_Type;
      Result     : access Params_Stream_Type);

   procedure Establish_RPC_Receiver(
      Partition : in Partition_ID;
      Receiver  : in RPC_Receiver);

private
   ... -- not specified by the language
end System.RPC;

A value of the type Partition_ID is used to identify a partition.
An object of the type Params_Stream_Type is used for identifying the particular remote subprogram that is being called, as well as marshalling and unmarshalling the parameters or result of a remote subprogram call, as part of sending them between partitions.
The Read and Write procedures override the corresponding abstract operations for the type Params_Stream_Type. Dynamic Semantics
The Do_RPC and Do_APC procedures send a message to the active partition identified by the Partition parameter.
After sending the message, Do_RPC blocks the calling task until a reply message comes back from the called partition or some error is detected by the underlying communication system in which case Communication_Error is raised at the point of the call to Do_RPC.
Do_APC operates in the same way as Do_RPC except that it is allowed to return immediately after sending the message.
Upon normal return, the stream designated by the Result parameter of Do_RPC contains the reply message.
The procedure System.RPC.Establish_RPC_Receiver is called once, immediately after elaborating the library units of an active partition (that is, right after the elaboration of the partition) if the partition includes an RCI library unit, but prior to invoking the main subprogram, if any. The Partition parameter is the Partition_ID of the active partition being elaborated. The Receiver parameter designates an implementation-provided procedure called the RPC-receiver which will handle all RPCs received by the partition from the PCS. Establish_RPC_Receiver saves a reference to the RPC-receiver; when a message is received at the called partition, the RPC-receiver is called with the Params stream containing the message. When the RPC-receiver returns, the contents of the stream designated by Result is placed in a message and sent back to the calling partition.
If a call on Do_RPC is aborted, a cancellation message is sent to the called partition, to request that the execution of the remotely called subprogram be aborted.
The subprograms declared in System.RPC are potentially blocking operations. Implementation Requirements
The implementation of the RPC-receiver shall be reentrant, thereby allowing concurrent calls on it from the PCS to service concurrent remote subprogram calls into the partition. Documentation Requirements
The implementation of the PCS shall document whether the RPC-receiver is invoked from concurrent tasks. If there is an upper limit on the number of such tasks, this limit shall be documented as well, together with the mechanisms to configure it (if this is supported). Implementation Permissions
The PCS is allowed to contain implementation-defined interfaces for explicit message passing, broadcasting, etc. Similarly, it is allowed to provide additional interfaces to query the state of some remote partition (given its partition ID) or of the PCS itself, to set timeouts and retry parameters, to get more detailed error status, etc. These additional interfaces should be provided in child packages of System.RPC.
A body for the package System.RPC need not be supplied by the implementation. Implementation Advice
Whenever possible, the PCS on the called partition should allow for multiple tasks to call the RPC-receiver with different messages and should allow them to block until the corresponding subprogram body returns.
The Write operation on a stream of type Params_Stream_Type should raise Storage_Error if it runs out of space trying to write the Item into the stream. NOTES
(8) The package System.RPC is not designed for direct calls by user programs. It is instead designed for use in the implementation of remote subprograms calls, being called by the calling stubs generated for a remote call interface library unit to initiate a remote call, and in turn calling back to an RPC-receiver that dispatches to the receiving stubs generated for the body of a remote call interface, to handle a remote call received from elsewhere.

Go to the first, previous, next, last section, table of contents.