OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
blocking on the call to rpc_server_listen( ) which was made earlier. If max_calls_exec
was specified to be greater than 1 in that call, other threads may still be executing at this
time in response to other requests that have been received from other clients. In any
case, the call to rpc_server_listen() will not return until one of the server’s own
management routines, or a client, makes a successful call to
rpc_mgmt_stop_server_listening(). If this happens, the RPC runtime will stop
accepting incoming client requests to the server. When all the currently executing
operations have been completed, the call to rpc_server_listen( ) will return.
The other way that execution can be thrown out of the rpc_server_listen() call is as a
result of a signal or exception.
From the server’s point of view, the result of completing the remotely called routine is
that it reenters the listen loop, waiting for further remote calls. The server’s runtime
handles all the communications details of actually sending any requested data to the
client.
From the client’s point of view, the server’s return at the end of its remotely called
routine results in the client’s returning from a seemingly locally executed routine.
1.7.5.1 Continuing
The client now goes on about its business, which may include performing other remote
procedure calls.
Note that there is no housekeeping burden placed on the client with regard to the
termination of the relationship with a server. However, a long-lived client might want to
make use of the rpc_binding_free( ) routine to free memory that was allocated for no-
longer-used handles. The client should also call rpc_ns_binding_import_done( ) to
clean up the resources used by the NSI routines. If another binding handle will be
needed later on, then rpc_ns_binding_import_begin( ) will be recalled.
1.8 About DCE Programming Style
The (hereafter, the Style Guide) attempts to bridge a gap. On one side stands the tutorial
and reference material provided by the rest of the OSF DCE Application Development
Guide and by the OSF DCE Application Development Reference. In theory, this material
provides complete documentation of the mechanisms of DCE application programming.
In particular, it documents the syntax and semantics of every DCE API interface and IDL
construct and provides a service-by-service guide to their use.
On the other side stands the formal application portability specification provided by the
AES/DC. This provides a policy guide of a specific kind: if applications wish to be
portable among DCE implementations, they need to follow the AES guidelines.
Between these two poles of DCE documentation, there is still a great deal of room to
maneuver. The DCE application programming facilities provide such a large number of
1− 34 Tandem Computers Incorporated 124246