|
|
Interprocess Communication: Programmer's Guide: HP 3000 MPE/iX Computer Systems > Chapter 3 IPC Using File System IntrinsicsHow 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.
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. 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 “IPC Processing”, 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. 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/iX 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/iX 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/iX 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 “IPC Processing”: Figure 3-1 IPC Processing
"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:
The reasoning is as follows:
In Figure 3-1 “IPC Processing”, 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/iX will wake up the waiting intrinsic and return an EOF condition. 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. |
|