Some notes on the RPC update

One of the recent updates to Allegro CL 6.2 was a full-fasl patch for the Remote Procedure Call (rpc) facility. This update added new functionality and modified some existing functionality. The rpc.htm document was also updated to reflect the changes.

In this note, we discuss one of the new RPC features: a facility to manage a pool of Allegro CL light-weight processes (lwp's) used to execute in-coming remote calls. Each in-coming remote call is executed in a separate Allegro CL lwp. The RPC process pool facility allows an application to manage this activity with several numeric parameters:

  • the maximum number of simultaneously active lwp's allowed to execute in-coming remote calls
  • the number of idle processes retained in the pool
  • the number of minutes an idle process stays in the pool

When the number of in-coming remote calls exceeds the maximum number of simultaneously active lwp's, calls are queued until an opening occurs. When an in-coming call is completed, the lwp used for the call is assigned to the next call waiting in the queue, or it is returned to the idle pool. If the pool is full, the idle lwp is discarded. If a lwp sits in the pool for the maximum retention period, it is discarded from the pool.

On Windows platforms, where Allegro CL lwp's are implemented as Windows threads, creating a new lwp is a moderately resource-intensive operation. Recycling lwp's can significantly improve the performance of an application.

On Unix platforms (where Allegro CL lwp's are implemented in Lisp) lwp recycling is not necessary for performance reasons, but it may still be useful to manage the resources allocated to in-coming remote calls.

The function rpc-process-pool is the programming interface to this facility. By default, the process pool is enabled, with a limit of 10 on the number or retained lwp's and a retention period of 15 minutes. The limit on the maximum number of simultaneous lwp's for in-coming calls is 15. These default values are usually suitable so the typical user does not have to take any specific action to benefit from process pools. However, the following examples of calls to rpc-process-pool illustrate several other interesting configurations:

  cl-user(23): (rpc-process-pool :active 1)

In this case only one lwp is allowed to execute an in-coming call at any one time. Thus, all in-coming calls are serialized into a single lwp. This configuration could be useful to guarantee sequential access to a resource shared by all the RPC clients.

  cl-user(24): (rpc-process-pool :active 10 :limit 0)

In this case, there is no pool of retained idle lwp's, but there is some limit on the impact in-coming calls may have on the server. At most 10 in-coming calls will be handled simultaneously; additional calls will be queued and executed as resources allow.

  cl-user(25): (rpc-process-pool :new :none)

In this case, there is no pool of lwp's at all, and each in-coming remote call is executed in a freshly created lwp that is discarded when the call is completed. This configuration is sufficient when the expected number of simultaneous calls is small.

Copyright © 2018 Franz Inc., All Rights Reserved | Privacy Statement Twitter Google+