|
|
United States-English | |
|
|
 |
|
HP 9000 Networking: HP FTAM/9000 Programmer's Guide > Chapter 4 Using Support Functions
Responding to Asynchronous Calls |
|
|
The MAP 3.0 Event Management interface plays a central role in your use of asynchronous calls to FTAM functions. It is common to have multiple asynchronous function calls outstanding. As responses to these calls come in, the FTAM Service Provider Process (SPP) queues them. The Event Management interface takes the first response off this queue and returns it to the caller as a MAP 3.0 event. At the same time, the Event Management interface updates the called function's inout DCB to show the outcome of the asynchronous call. The FTAM/9000 implementation of MAP 3.0 Event Management consists of three functions, each used under slightly different circumstances. The functions are:
Whenever possible, use only em_wait() to wait for and obtain MAP events. Since em_wait() is the only one of the three defined by the MAP 3.0 specification, using it eases porting to non-HP platforms. However, em_wait() is also very limited. Sometimes, you may have no alternative but to use one or both proprietary functions instead of or in addition to em_wait(). Following are some guidelines for each of the three event management functions. The em_wait() function enables you to suspend application processing until a MAP event occurs. However, em_wait() does not provide for waiting on any non-MAP events. Use em_wait() when your application needs to wait exclusively on MAP 3.0 events. For example, if your application is a daemon process which interacts only with the OSI network via FTAM protocols. The em_hp_select() function is a Hewlett-Packard proprietary extension to the MAP 3.0 specification. It can be regarded as a hybrid of the MAP 3.0 em_wait() function and the HP-UX select() system call. It is located in the common MAP library (libmap.a). Use em_hp_select() instead of em_wait() when your application needs to wait on MAP events, plus non-MAP events that can be represented by a file descriptor and waited on via the HP-UX select() system call. This may be true if your application is interactive (for example, using asynchronous input from Terminal I/O or the X11 Window system). It also may be true if your application needs to communicate with other processes via named pipes or domain sockets as well as perform FTAM operations over the OSI network. In addition, use em_hp_select() instead of em_wait() if your application would otherwise need em_wait() to return when interrupted by a signal. The em_hp_select() function does not return by itself when interrupted by a signal, but techniques exist to simulate this behavior. See the section on handling signal interrupts with em_hp_select(). The em_hp_sigio() function is another Hewlett-Packard proprietary extension in the common MAP library (libmap.a). It enables the Event Management interface to notify your application via the SIGIO signal when there is a MAP 3.0 event pending. However, em_hp_sigio() does not return any MAP events itself. Therefore, it should complement your use of em_wait() or em_hp_select(). Use em_hp_sigio() along with em_wait() or em_hp_select() when your application needs to control the dispatch of MAP and non-MAP components by using signals and/or semaphores to indicate when a particular component has work to do. This is often necessary when porting applications from other operating systems such as AT& T's System V Unix or DEC's VMS.
This section describes general use of asynchronous calls with em_wait(). For additional details on em_wait(), refer to the HP FTAM/9000 Reference Manual. Call functions asynchronously when making multiple requests and when the order in which results are processed does not matter. If you make an asynchronous call, you can perform other operations while your request is being processed. Following are examples of when to call functions asynchronously or synchronously.
The following text describes the sequence of making asynchronous requests and checking for their successful return from the responder.
Following is an example of the use of em_wait(). This example creates and opens a file by asynchronously calling ft_bgroup(), ft_create(), and ft_open(), followed by synchronously calling ft_egroup(). These functions were called with return_event_names of 1, 2, 3, and 0, respectively. The em_wait() function waits on these calls.
This section describes how to use em_hp_select() and provides two program examples. For additional details, refer to the HP FTAM/9000 Reference Manual.
Multiple asynchronous FTAM functions calls are commonly outstanding at the same time. An application may also need to interact with other processes using an interprocess communication mechanism (for instance, HP-UX Domain Sockets or pipes). It may also require response to asynchronous events from a terminal keyboard or window system (for instance, X- Windows). The MAP 3.0 Event Management interface does not provide an independent method to wait on both FTAM and non-FTAM events simultaneously. Therefore, HP added a proprietary function—em_hp_select()—to provide this capability. Neither em_wait() nor em_hp_select() automatically return when interrupted by a signal. However, the following section describes a way to make a signal generate a non-FTAM event, causing em_hp_select() to return on receipt of a signal. Use the em_hp_select() function when an application must simultaneously wait for both an FTAM and a non-FTAM event to occur. Without em_hp_select(), the application would need to implement a "busy- wait" loop to poll for the FTAM and non-FTAM events. However, this technique is very expensive in terms of CPU utilization, and degrades system performance. This is unacceptable for most real-time or highly interactive applications. Therefore, HP provides em_hp_select() as an alternative method for waiting on both FTAM and non-FTAM events. The em_hp_select() function suspends processing of the application until an event occurs. While the application is suspended (i.e, blocked), it does not contribute to the demand for CPU time. Therefore, the busy-wait logic can be replaced with the following:
If you need to wait only on FTAM events, use the em_wait() function. If you need to wait only on non-FTAM events, use the HP-UX select() system call. However, if you need to wait on both types of events simultaneously, use the em_hp_select() function. Any combination of em_wait(), select(), and em_hp_select() within the same program is valid; all three functions are compatible with one another. The following program example illustrates how to use em_hp_select() to wait on FTAM and non-FTAM events simultaneously. The program reads commands from stdin and starts the requested FTAM operation. The operation is performed asynchronously so that new commands can be read in before the previous operation completes. The operation results are processed as they complete. This program calls two functions to process the FTAM and non-FTAM events. The logic for these functions is not shown in the example; however, a brief description of each function follows. This function processes the non-FTAM events by reading and parsing a command line string from stdin. If the command is a "Quit" command, the function returns TRUE to indicate termination. Otherwise, the appropriate FTAM operation is initiated asynchronously. In this case, the function returns FALSE to indicate more commands can be read from stdin. For example, this function could be a batch entry console for file management. Several file transfers could be started without having to wait for each transfer to complete before starting the next. This function processes the FTAM events by performing some action on the results of the FTAM operation that completed. The operation is identified by the map_event passed as input. If map_rc equals SUCCESS, the inout_dcb for the operation contains the outcome of the operation. Otherwise, the map_rc equals EME032_IPC_ERROR; the operation fails and the inout_dcb does not contain valid information. The specific actions involved with processing a completed FTAM event are specific to the particular event, and could be as simple as logging the results to an output file.
Suppose an application needs the em_wait() function to return prematurely if a signal interrupt occurs. One case where this is applicable is when receipt of a signal should cause a new FTAM operation to be initiated or an outstanding operation to be aborted (e.g., the application is being terminated abruptly). Since FTAM functions are not reentrant, the application needs to force em_wait() to return prematurely so the appropriate action can be taken upon receipt of the signal. The em_wait() and em_hp_select() functions cannot detect signal interrupts and automatically return. However, you can cause em_hp_select() to return when interrupted by a signal. This involves translating the signal interrupt into an em_hp_select() non-FTAM event while executing the signal handler. When em_hp_select() resumes processing after the signal handler completes, the non-FTAM event will be detected and em_hp_select() will return. Several techniques exist to translate the signal interrupt into an em_hp_select() non-FTAM event. One way is to use an HP-UX pipe as follows:
The following program example illustrates how to use em_hp_select() and an HP-UX pipe to implement the signal handling technique described previously.
This section describes how to use em_hp_select() and provides a program example. For additional details, refer to the HP FTAM/9000 Reference Manual. Use em_hp_sigio() to enable the MAP Event Management interface to generate SIGIO signals whenever an asynchronous MAP event is pending. Unlike the other MAP event management functions, em_hp_sigio() does not return a MAP event to the caller. Instead, it merely puts the MAP event management interface into an extended capability mode. By using this capability, you can suspend the processing of your application until any of a variety of signals or semaphore operations cause your application to resume execution. Then, only after the SIGIO signal has been received do you need to call em_wait() to obtain the MAP event that is pending. Furthermore, since you know the MAP event is already pending, you can call em_wait() with a zero timeout to obtain the event and return immediately. The following program example illustrates one possible use of em_hp_sigio(). The program initiates and processes two types of events: MAP events in the form of FTAM and/or FTAM asynchronous operations, and Non-MAP events that take the form of SIGUSR1 signals. The em_hp_sigio() function is used to enable SIGIO signal notification in the MAP Event Management interface, and em_wait() is used to process the MAP event after SIGIO is caught.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
