HP 3000 Manuals HP 3000 Manuals
How To Use IPC--A Simple Case IPC can be relatively easy to set up. Suppose that a large programming task is to be divided into two processes. One process will interface with the user. This process is referred to as the "supervisor" process. It does some processing tasks itself and offloads others to a "server" process. This process only handles requests from the supervisor and returns the results. The following paragraphs describe how to set up the communications between these two processes.
NOTE In this chapter, the MPE XL versions of the file system intrinsics (for example, HPFOPEN) will be discussed. You may also use the MPE V/E versions of these intrinsics (for example, FOPEN) to perform IPC; there is no need to rewrite existing programs, since these intrinsics are compatible with respect to IPC.
Program Structure Like most other files, message files need to be opened explicitly with the HPFOPEN intrinsic. Two-way communication is needed, so each process opens two message files: a Command File for supervisor-to-server commands and a response file for server-to-supervisor responses. The supervisor opens the command file with WRITE-ONLY access, and the response file with READ-ONLY access. The server opens the Command File with READ-ONLY access, and the response file with WRITE-ONLY access. The HPFOPEN parameters are similar to any other HPFOPEN these processes would perform on another file. The processes communicate by using file names known to both of them. Message File Names To use IPC, processes must reference each other through a known file name. This means that the file must be in a directory that is available to all accessors. In the example in Figure 3.1, either a :BUILD must be done previously, or one process must first HPFOPEN the file as new and FCLOSE it as permanent, to put the file in the permanent file directory. The file can be created as temporary if all accessors are running under the same job or session. If you are concerned about security, create the file with a lockword. IPC Processing In addition to HPFOPEN, these processes use three other file system intrinsics to perform IPC: FREAD, FWRITE, and FCLOSE. These intrinsics are used exactly as they would be for any other type of file. When the server starts executing, it performs an FREAD on the Command File. The Command File is empty, so the server process blocks in FREAD instead of getting an end-of-file condition. As part of the supervisor's processing, it eventually writes to the Command File. Since the file is not full, there is nothing to block this FWRITE, so it completes almost immediately. The supervisor then reads the response file, which, since it is empty, causes the supervisor process to block. MPE XL notices that data has been written to the Command File, and that the server process is waiting in FREAD for data from that file. MPE XL moves the data to the address that the server passed in the FREAD intrinsic, deletes the record from the Command Message File, and restarts that process. The server exits from the FREAD and processes the command. When it has finished processing the command, the server writes its answer to the response file. At this point the server is finished. It can terminate, or it can issue another FREAD on the Command File and start the sequence over again. MPE XL moves the response data to the supervisor's buffer, deletes it from the file, and restarts the supervisor at the FREAD. The supervisor continues processing, possibly repeating the cycle. Eventually both processes close each of their files as part of terminating. These processes are illustrated in the diagram shown in Figure 3.1: SUPERVISOR SERVER v v HPFOPEN "command" file HPFOPEN "command" file HPFOPEN "response" file HPFOPEN "response" file . v . FREAD "command" file . . (processing) | . . | (blocked) . . | . T v IPC | (fread . I FWRITE "command" file --------> _ completes) . M v . . E FREAD "response" file . . | . (processing) . | (blocked) . v | . | (fread IPC v _ completes) <--------- FWRITE "response" file v v FCLOSE "command" file FCLOSE "command" file FCLOSE "response" file FCLOSE "response" file v v Figure 3.1. IPC Processing End-of-File (EOF) Conditions "EOF conditions" may prevent an I/O from completing (for example, an FREAD from an empty file, or an FWRITE to a full file). The I/O intrinsic may return an end-of-file indication, or it may wait until the condition is resolved (a record becomes available for the FREAD, or space in the file becomes available for the FWRITE). The intrinsic waits if an EOF condition is encountered and either: * There is an "opposite accessor" to the file, or * This is the first I/O on this file since it was opened. The reasoning is as follows: * An "opposite accessor" is a process that is performing the opposite function on a file, for instance, an FWRITE when the process is waiting to perform an FREAD. If there is an opposite accessor, it is possible that the I/O request will be satisfied eventually. (If there were no opposite accessors, the process might wait forever.) * When processes start up, there may be a "race" condition in which it is difficult to predict whether one process's I/O request will be made before another process's HPFOPEN. For this reason, the first call to an I/O intrinsic will wait if there is an EOF condition. This gives the opposite accessor time to open the file. * Finally, a process may always want to wait rather than receive an EOF. It can do this by requesting "extended wait." This is discussed in more detail in Chapter 4. If extended wait is explicitly enabled, the process will always wait on an EOF condition. In Figure 3.1, the server can open the Command File and issue the FREAD before the supervisor opens the Command File. The server's FREAD on the Command File waits because it is the first I/O after the open. But suppose that, after the first command is processed, the server issues another FREAD on the Command File, and the supervisor has terminated unexpectedly. The second FREAD will receive an EOF, signaling that something is wrong. This FREAD receives an EOF because the FREAD is not the first I/O from the server on the Command File, and there are now no writers accessing the Command File. An FCLOSE by another process can cause an intrinsic that is waiting on an EOF condition to stop waiting and receive an EOF. If the process that is waiting is not using extended wait, and the last process that can resolve the EOF condition does an FCLOSE on the file, MPE XL will wake up the waiting intrinsic and return an EOF condition. Recovery From Abnormal Terminations In the event of an abnormal termination of the processes involved in IPC, some unread records may be left in the message file. Some applications are concerned only with current data and do not want to see unprocessed data from a previous run. The simplest solution is to programmatically :PURGE and :BUILD all message files as part of the initialization processing. Another possibility requires that the writer always open the file first. (The writer is the process sending messages to the message file.) If the writer's HPFOPEN specifies an access type option (item #11) of WRITE access only (item=1), and this is the only process with the file open, the records are automatically purged. If the writer's HPFOPEN specifies an Access Type Option of APPEND (item=3), then the old records are kept and the new records added to the end. Note that if the reader opens the file first, regardless of the writer's access type, the records are kept. (The reader is the process using FREAD to receive messages from a message file.) To recover the data cleanly in an application in which the reader opens the file first, use FLOCK to prevent the writer from altering the file. Then use FREAD to read all the records and either discard or process them. Sample Programs For sample programs illustrating the use of message files and WAIT I/O to perform IPC, refer to Appendix B.