One of the most universally praised features of the UNIX operating system, is its ability to ``pipe'' the sequential output of one process into the sequential input of another.
Similar producer-consumer pipe-lines can readily be formed using IO, simply by connecting the appropriate I/O ports of the producer and consumer. Neither producer, nor consumer need necessarily be aware that their I/O operations do not end up in files. As already described, the buffering strategy automatically ensures that the producer will be delayed until the consumer has made a buffer available to receive the producer's output. The out values of IO's parameters can simply be ignored.
However, this form of pipe-lining is not as transparent as the form provided by UNIX. In fact, it is only completely transparent when the producer and consumer write and read byte strings of exactly the same length. If the consumer tries to read 256 bytes from its input ``file'', but the producer writes only 128 bytes, the consumer's read returns only 128 bytes. Furthermore, had the consumer requested 64 bytes, the producer's write would fail.
This is not so much a mistake as a feature. UNIX-style pipe-lining is too transparent to use as a general-purpose IPC mechanism. Furthermore, the implicit buffer accessible to both producer and consumer is not very desirable in distributed systems. Moreover, UNIX-style pipe-lining can be provided, using IO, simply by inserting a buffer process between the producer and consumer.
It should also be noted that a process consuming a text stream from file or pipe, by reading a line at a time, in any case has to operate on a basis of ``ask for a long line, but be prepared for a short one''. Generalizing the I/O subroutine library will therefore make reading the ``hand-shaked'' pipe offered by IO, indistiguishable from reading a text file or a UNIX-style pipe as text.
Prof Herman Venter