- Declaring a Connection Library
- Establishing Connections
-
- Explicitly Linking Connection Libraries
- Implicitly Linking Connection Libraries
- Directly Linking Connection Libraries
- Controlling Connection Library Sharing
- Approving a Connection
- Monitoring Connection State
- Matching Connection Library Objects
- Initiating Connection Libraries
- Unreadying a Connection Library
- Delinking Connection Libraries
- Using PROLOG and EPILOG Procedures
- Using Connection Library Objects
Connection libraries are a special type of library that can be implemented only in ALGOL or NEWP. The use of connection libraries provides the following features that are not available to server libraries:
-
A two-way exchange of objects between libraries through a linkage called a connection.
-
The ability of a single program to export more than one library simultaneously.
-
The ability to specify multiple connections for a library, where the connections can lead to different libraries in different programs.
-
The ability to monitor and control each connection with another library separately.
-
The ability to declare objects that are local to each connection of the library.
When to Use Server Libraries Instead
Connection libraries are a good choice for projects that make use of these special features. However, if you do not need to use any of these features, you might find it easier to implement the project using server libraries.
Mixing Connection Libraries, Server Libraries, and Client Libraries
Linkages can exist between connection libraries, between a connection library and a server library, or between a connection library and a client program. However, to simplify the explanation, this section generally discusses connection libraries as if they could link only to other connection libraries. For an overview of linkages between connection libraries, server libraries, and client programs, refer to Other Library Linkage Methods later in this section.
Connection Library Performance Consideration
When libraries are used for a two-way exchange of objects, such as in the following cases, the system must execute expensive cleanup code when a library delinks:
-
A connection library that both imports and exports objects
-
Multiple connection libraries between two stacks, some of which export and some of which import objects
-
Circular libraries
This expense can become extreme when many stacks are included in the process families. It is advisable to design applications to avoid a two-way exchange of objects between stacks whenever possible. For more information, refer to Hazards of Circular Connections.
