FIFO Characteristics

FIFO Characteristics

FIFOs have most of the same characteristics as other sequential files, except that READs and WRITEs can occur in any order.

The following characteristics of FIFO behavior may be helpful in using them effectively.

With READ:

• If a READ is done while there is no data in the FIFO:

The process hangs until data is put into the FIFO by another process, or the READ times out, when a timeout is specified.

The following table shows the result and the values of I/O status variables for different types of READ operations on a FIFO device.

With WRITE:

• The FIFO device does non-blocking writes. If a process tries to WRITE to a full FIFO and the WRITE would block, the device implicitly tries to complete the operation up to a default of 10 times. If the gtm_non_blocked_write_retries environment variable is defined, this overrides the default number of retries. If the retries do not succeed (remain blocked), the WRITE sets $DEVICE to “1,Resource temporarily unavailable”, $ZA to 9, and produces an error. If the GT.M process has defined an EXCEPTION, $ETRAP or $ZTRAP, the error trap may choose to retry the WRITE after some action or delay that might remove data from the FIFO device.
• While it is hung, the process will not respond to .

With CLOSE:

• The FIFO is not deleted unless the DELETE qualifier is specified.
• If a process closes the FIFO with the DELETE qualifier, the FIFO becomes unavailable to new users at that time.
• All processes currently USEing the FIFO may continue to use it, until the last process attached to it CLOSES it, and is destroyed.
• Any process OPENing a FIFO with the same name as a deleted FIFO creates a new one to which subsequent OPENs attach.

The default access permissions on a FIFO are the same as the mask settings of the process that created the FIFO. Use the SYSTEM, GROUP, WORLD, and UIC deviceparameters to specify FIFO access permissions. File permissions have no affect on a process that already has the FIFO open.

Considerations in Implementing FIFOs

As you establish FIFOs for interprocess communication, consider whether, and how, the following issues will be addressed:

• Do READs occur immediately, or can the process wait?
• Are timed READs useful to avoid system hangs and provide a way to remove the process?
• Does the WRITE process need to know whether the READ data was received?
• Will there be multiple processes READing and WRITEing into a single FIFO?

Error Handling for FIFOs

Deleting devices (or files) created by an OPEN which has an error has deeper implications when that device, especially a FIFO, serves as a means of communications between a two processes. If one process OPENs a FIFO device for WRITE, there is an interval during which another process can OPEN the same device for READ. During that interval the writer process can encounter an error (for example, an invalid parameter) causing GT.M to delete the device, but the reader process can complete its OPEN successfully. This sequence results in a process with an orphaned device open for READ. Any other process that OPENs the same device for WRITE creates a new instance of it, so the reader can never find data to READ from the orphaned device. Since GT.M has insufficient context to enforce process synchronization between reader and writer, the application must use appropriate communication protocols and error handling techniques to provide synchronization between processes using files and FIFOs for communication.

GT.M Recognition of FIFOs

Like a sequential file, the path of a FIFO is specified as an argument expression to the OPEN, USE, and CLOSE commands. A device OPENed with a FIFO deviceparameter becomes a FIFO unless another device of that name is already OPEN. In that case, OPENing a device that has previously been OPENed by another process as a FIFO causes the process (the process here is the process trying to open the FIFO) to attach to the existing FIFO.

FIFO Device Examples

The following two examples represent a master/slave arrangement where the slave waits in a read state on the FIFO until the master sends it some data that it then processes.

Example:

set x="named.pipe"
open x:fifo
do getres
use x write res,!

This routine opens the FIFO, performs its own processing which includes starting the slave process (not shown in this code fragment).

Example:

set x="named.pipe"
open x:fifo
use x read res
do process(res)

This routine waits for information from the master process, then begins processing.

FIFO Deviceparameter Summary

The following table summarizes the deviceparameters that can be used with FIFOs.