RemoteProcCall

Semantics

The system designer may specify the Rename property in the property list of an instantiation of a RemoteProcCall connector to bypass the semantic check on the names of the players (meaning that they do not have to be the same). In such a case, the UniCon compiler detects and repairs such name mismatches in the underlying system implementation.

Role types

Definer

a definer of a remote function or procedure (i.e, a function or procedure defined in a process so that it is callable from other processes)

Caller

a caller of a remote function or procedure

Properties

InstFormals (P)

The syntax for an InstFormals property in a connector of type
RemoteProcCall is a comma-separated list of <parameter>s enclosed in parentheses. A <parameter> consists of an <identifier>, followed by a `=', followed by a <complex string> or the language keyword NODEFAULT. A <complex string> is a simple "string" or a sequence of "string"s concatenated by the `&' character:

INSTFORMALS (first_parameter = "an initial value",

second_parameter = "a much" &
"longer initial value that " &
"will not fit on one line",
third_parameter = NODEFAULT)

IDLType (P, I)

The syntax for an IDLType property in a connector of type RemoteProcCall is one of the two keywords Mach or RPCL, (optionally) enclosed in double-quotes, and surrounded by parentheses:

IDLTYPE (Mach)
IDLTYPE ("rpcl")

If no IDLType property is specified in the protocol property list of a RemoteProcCall connector, the default value is "rpcl".

Rename (P, I)

The Rename property has no associated value. The syntax, therefore, is simply:

RENAME

Semantic Checks

1. The name of the player playing the Caller role must be identical (including case) to the name of the player playing the Definer role, unless the Rename property is specified in the connection.
   
   
2. The number of arguments, the data types of the arguments, and the return type in the signature of the player playing the Caller role must be identical (including case of identifiers) to the number of arguments, the data types of the arguments, and the return type in the signature of the player playing the Definer role. (Warning only)
   
   

Implementation Semantics

The underlying mechanism that implements both the Mach and RPCGen message passing facilities is essentially the same. Both assume that applications implement remote procedure and function calls as local routine calls, and remote function and procedure definitions as local routine definitions. This model requires that processes making remote procedure calls contain source code that intercepts the local routine calls implementing the RPCs, builds a message containing the arguments of the call, and hands the message off to the operating system for delivery to the process containing the routine definition. It also requires that processes exporting remote routine definitions contain source code that extracts the arguments from service request messages from calling processes, makes the local routine call, builds a return message containing any results from the routine call, and hands the return message off to the operating system for delivery to the calling process. Generating this "glue code" in each process can be time consuming, intricate, and error prone. Therefore, both the Mach facility and the RPCGen facility provide a code generator for generating this code from their own brand of interface definition language (IDL). The Mach IDL is called the Mach Interface Generator (MIG) language. The RPCGen language is called Remote Procedure Call Language (RPCL).

UniCon automatically generates the IDL specification of the RPC interface between two Process or SchedProcess components directly from the UniCon definitions of the components. Then, at system construction time, the correct generation tool (i.e., MIG or RPCGen) produces the source for the "glue code" from the IDL specification, and the code is compiled and linked into the correct processes. The system designer is spared having to know the details of implementing the glue code directly.

In addition to the glue code required between processes making RPCs, each communication model requires processes making RPCs to communicate once during system initialization with a "name" server that is executing in the operating system environment. This name server is the mechanism by which server processes register their services (i.e., the remote procedure definitions) for general use, and by which client processes locate the services they will request. UniCon generates the initialization code in each process that is responsible for registering or locating services at run-time. This code runs as the "main" program in the environment; it registers/locates all of the services exported/imported by the Process or SchedProcess component implementing the process, and then calls the local routine definition that implements the main functionality of the component (recall that Process and SchedProcess components are implemented as function or procedure definitions).

The system designer need not know any details whatsoever regarding the implementation of the underlying mechanisms for RemoteProcCall connections. Indeed, remote procedure calls and definitions in the underlying implementation are identical to local routine calls and definitions. There literally is no difference. UniCon does all of the work in turning them into remote procedure calls and definitions. Similarly, at the UniCon architecture description level, RemoteProcCall connectors are nearly identical to ProcedureCall connectors in how they are specified, with the only exception being that RemoteProcCall connections require the specification of the IDLType property.

If a name mismatch is detected in a RemoteProcCall connection and the Rename property is specified, the UniCon compiler renames both identifiers in the source code of the implementation to a third, UniCon-generated identifier to resolve the mismatch. The renaming occurs at compile-time via macro names supplied with the -D option to invocations of the C language compiler.

Author: Gregory Zelesnik

Last Modified: May 12, 1996