The following figure shows a remote procedure executed asynchronously. As in Figure 1, the client is an event-driven GUI and the application sets a simple status flag (Done) to indicate that the remote request has completed.

In this implementation, the client first executes async.p as an asynchronous remote procedure (1, specified by the ASYNCHRONOUS keyword on the RUN statement). The client immediately continues execution, until it reaches the WAIT-FOR statement to get events (2) at the same time that the AppServer executes the remote request. Thus, at this point (1 and 2), the client and remote request are running in parallel. The client can continue to execute, calling additional asynchronous remote procedures on the same or different AppServer connections.

As each asynchronous request completes (like async.p at 3), the client handles the results in a specified event procedure (4). This event procedure, specified in the asynchronous RUN statement, is essentially a "trigger" that executes on the client in response to a PROCEDURE-COMPLETE event posted to the client when the associated asynchronous request completes.

As with user-interface events, the client can handle PROCEDURE-COMPLETE events in the context of a blocking I/O statement, such as the WAIT-FOR statement (4), or by executing the PROCESS EVENTS statement. The AVM maps the PROCEDURE-COMPLETE event for each asynchronous request to the appropriate event procedure using a unique asynchronous request handle that is generated for each request (not shown). This handle provides the mechanism that you can use to monitor the status of each request.

Note that the example in the previous figure provides the same functionality as Figure 1. In fact, sync.p and async.p are identical, except for their names, which are changed for readability. The AppServer has no idea whether its procedures are being called synchronously or asynchronously. The type of request is entirely a function of the client and its implementation.

The main difference, is that the bStatus trigger in the previous figure tests the status of the remote request and performs actions based on whether the request finished, rather than invoking the request itself, as in Figure 1. Thus, the synchronous bottleneck is removed. In all such cases, the synchronous bottleneck is avoided by handling the results asynchronously.