_________________________________________________________________ sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Remote Asynchronous Call [RAC Classic] Submitted by: Steve N Date: June 3rd, 1992. Committee: Bruce D, Steve E, Rob G, Graham H, Joe K, Jarrett R, Bill S, Glenn S, Rangaswamy V 1. Summary RAC Classic is a set of interfaces intended to support an asynchronous calling mechanism for remote procedure calls. 2. Decision & Precedence Information This interface is approved as a committed interface. It may be introduced as such in a minor release. Its use, however, is disparaged. An exception is granted to the packaging dictum described in psarc/1991/061. This exception is granted only for the current implementation of librac. Introduction of any changes to the librac implementation in Sun platform software (other than bug fixes) requires approval by the Platform Software Architecture Committee. Documentation requirements for this interface are described in Appendix A: Technical Changes Required. 3. Opinion The compelling need the committee considered in approving an interface that is both "committed" and "disparaged" is to provide a means by which applications using remote asynchro- nous procedure calls can be easily moved from, for example, DOS to Solaris platforms. Given the lack of thread support in DOS and other volume platforms, the remote asynchronous call (RAC) interface is the only available means to support concurrent remote procedure call activity on such platforms. The interface is publically committed since the only reason to provide it is to ease porting of PC applications that use the existing RAC interface. We have no control over the definition of this interface whether we choose to declare it committed or uncommitted. Making it a privately defined Solaris interface misses the point of providing it at all. The interface is disparaged since it provides a "second way of doing the same thing". Synchronous calls with threads is the preferred means of provinding concurrency within Solaris. Further, use of this interface in its proposed implementation impacts the performance of "normal" remote procedure calls within a process. Further, the interface per se seems deficient in several ways with respect to [1] buffer management, [2] server load management, and [3] its failure to address other known asychronous call paradigms (such as multicast and peer-to- peer messaging) that may be useful in ONC and that Sun may someday want to support in a coherent manner. If the proposers had the time and felt they could swing the de-facto standard, they would "do it right". That's not the situation. Supporting RAC has side-effects on the performance of even synchronous remote procedure calls. To confine these side- effects to only those cases where asynchronous calls are specifically required, the RAC interface implementation in librac overloads libnsl definitions of some support routines that are used by both synchronous and asynchronous calls. The librac definitions of these routines provide for the buffer management that the RAC interface requires. This buffer management is estimated to add something like a mil- lisecond to every remote procedure call-be it RAC or syn- chronous. The proposed implementation avoids this cost by providing the versions of the support routines that include buffer management only when librac is loaded. The support routines are effectively redefined as needed. Normally the "fast" routines supporting only synchronous remote procedure calls are in effect. This implemention, however, violates the principle articu- lated in psarc/1991/061 that, for effective patch manage- ment, "Each component of the system can appear in only one package." In this case, however, the same group is respon- sible for the maintenance of both libraries. So as contem- plated in 061's dump example, an exception to the packaging requirement is granted for the proposed implementation. Steve N sketched a possible alternative implementation that might provide a purely additive interaction between the librac and libnsl packages. Steve felt, however, the con- struction and evaluation of such an implementation could not be done "soon enough", that is, within the time it seemed that the RAC interface should be made available to custo- mers. The committee encouraged Steve to remove the cross- dependency between librac and libnsl in any future implementation-perhaps by making use of the threads library in implementing the facilities librac provides or perhaps by some other means. The overloading of libnsl symbols by librac makes correct operation of the currently proposed implementation subject to (static) link order. The committee requires user docu- mentation defining the proper order and the consequence of improper link ordering be provided. It also requires that the dependency of librac on libnsl be defined in the librac implementation. The desired net effect is that: [1] the right thing happens automatically for dynamic linking and [2] the user knows what to do for static linking and what to look for in case of error. 4. Minority Opinion(s) None. 5. Advisory Information None. 6. Appendices 6.1. Appendix A: Technical Changes Required 1. Indication that this interface is disparaged and the possible (performance) side-effects on even synchronous remote procedure calls consequent to its use must be included in all Sun documentation describing such use. A reference to the prefered means of accomplishing the function of RAC-with synchronous calls in the Solaris multithreaded environment-should be provided. 2. Documention of the RAC interface must describe what happens when libnsl and librac are not loaded in the correct order. The librac library must be defined with a dependency on libnsl for dynamic linking. 6.2. Appendix B: Technical Changes Advised None. 6.3. Appendix C: Reference Material Man page