A Process component can behave in one of two ways. It can behave like a "server" process, providing services to other processes by exporting remote procedure definitions, or it can behave like a "client" process, requesting services from other processes via remote procedure calls. The distinction between client processes and server processes is important in UniCon because certain properties (e.g., the EntryPoint property) have different semantics based on the kind of Process being defined. To formalize the definitions, a client process is one that exports no remote procedure definitions, only calls. A server process is one that exports at least one remote procedure definition. A process that exports remote procedure definitions and calls is still considered to be a server (i.e., one that requires services from other processes in order to accomplish its work).
In addition to the static, compile-time "glue code," remote procedure calls require run-time support. Each process must perform some initialization in the environment before starting to perform its tasks. This initialization takes the form of looking up (client) or registering (server) services with a common "name server" process that executes in the environment. This is how client processes are able to locate services provided by server processes in the run-time environment. The UniCon compiler generates this run-time initialization code automatically for each process. It generates a "main" program that performs the initialization and calls the initial entrypoint in the source code provided by the system designer. The designer specifies this entrypoint name using the EntryPoint property.
The source code implementation of a client process must be a function or a procedure.
UniCon currently only supports implementations in the C programming language, so for now it must be a C function. The function can be named "main," however it will be renamed in this case since UniCon produces a "main" function for each process. The "main" function that UniCon produces performs any initialization required to support remote procedure calls between this and other processes, and then it calls the function that implements the client process. The process terminates when this function returns, so some sort of infinite processing (i.e., loop) may be required to keep the process active.
The source code implementation of a server process is different. It must be a collection of C functions, called service functions, plus optionally one additional worker function. The worker function, if present, will run in parallel with a UniCon-generated "main" program. It performs application-specific processing. The service functions become the callable remote procedures at run-time. UniCon generates a "main" function that performs initialization required to support remote procedure calls between this and other processes and loops forever waiting for service requests from other processes. This main function will call the appropriate service function to perform a requested service, and then send the results back to the client process that made the request.
The worker function must be implemented as a simple C function. Under Mach, the worker function may or may not loop forever. In RPCGen-based servers, the worker thread must not loop forever, and will be called periodically (after performing each service request, and every 10 milliseconds if no requests are forthcoming). The presence or absence of a worker function is specified by the presence or absence of the EntryPoint property in the interface property list of a server Process component. The name of the worker function is supplied as the value of this property.
Each service function must be a simple C function that does not loop forever, but rather eventually returns.
One final note: remote procedure calls on Mach systems require that the functions pass results back to client processes via the arguments of the function (i.e., the return value is passed back to the caller by modifying the location pointed to by one of the input arguments), rather than as the return value of the function. This is not the case for RPCGen-based services.
Author:
Last Modified: May 12, 1996