Filter
Top Products
Overview 5-3
21 Dec 2001
5-
Overview
Asynchronous Support Layer library works as a filter between
existing ACI libraries (version 3 or later) and the client
application, which wants to issue asynchronous ACI calls.
Since the native ACI interface is synchronous, a client had to
wait for the completion of the request. Now using special
programming techniques, developers who want to use ACI in
an asynchronous manner can use the Asynchronous Support
Layer library of this purpose.
How It Works
In early ACI releases, all programmers using the ACI library,
had to consider that any ACI call issued by the application
would wait until the work is complete. Now, each incoming
request is stored into the shared memory area and each
request is executed in forked process.
After the application issues a request, it is given a request ID.
The request ID is actually the process ID of the forked child
process. The operating system does not allow two processes
with the same ID. The request ID ensures the uniqueness of
each ID.
After the request is completed, it stores the results in the
appropriate location in that shared table and terminates. To
retrieve the information back to the client, define a special
function that terminates (SIGCHLD) a child process. This
routine could also transmit the data into an application
internal data buffer and free the entry in the table. Doing this
ensures that the entry (process) ID will never be repeated in
the shared memory table.
Sadmin Sample Application
For the convenience and ease of understanding the
programming techniques required to write the asynchronous
ACI applications, the sadmin sample application is provided.
This application represents a cut version of the standard
dasadmin application. It the following commands:
•mount: mount a volser
• dismount: dismount the volser or force the drive to
dismount
• insert: insert volsers