Unix is designed so that virtually all I/O (both file and device) takes place using the stream abstraction model. This was a good design choice at the time of Unix's creation because much of the hardware that DEC's PDP series of computers interfaced with used sequential I/O. Modern computers are often different in that they have many devices that use memory-mapped I/O (such as bitmapped displays). Streams are not a good abstraction for memory-mapped I/O devices, and so for many modern computers the stream I/O model is inappropriate.
Stream-based I/O works best for applications that operate on their data sequentially. In fact, it is a necessity for computer systems (like DEC's PDP computers) that can only access 16bit addresses because any other I/O model would limit the size of data that they could easily work with. Even in modern computers the stream model still suits disk I/O well because most applications read and write files to disk sequentially. In older systems (such as the PDP-11 described in the paper) the stream I/O model was also good for device I/O because its devices typically operate on data sequentially.
For modern memory-mapped computer devices (like bitmap displays), random I/O is no more costly than sequential I/O. The stream abstraction is not appropriate for these devices because it forces the programmer to work with randomly accessible data in an sequential manner. This is unintuitive and potentially inefficient (depending on the system's implementation). Simulating random I/O on top of a stream based I/O model (using the lseek command), is still not a good solution because it presents the wrong abstraction to the programmer. Abstraction is good when it simplifies unnecessary complications, but in this case the stream abstraction only adds additional restrictions upon the programmer and makes its interface more complex.
Consider the case where a vertical line is being drawn on a bitmapped display which stores screen data in memory by rows. A random I/O-style interface would need to make a number of OS calls for each pixel in the line that is being drawn, with each call specifying each pixel's coordinates. A stream based interface would require that the program alternately seek to the correct spot in the stream and write to the stream for each pixel that needs to be drawn. In this example, the stream abstraction is not a good one because it adds complexity (and potentially reduces the efficiency of the system.)
Overall, the stream is a very useful abstraction in simplifying data I/O. However, it is not appropriate for use with modern computer devices that operate using memory-mapped I/O.
Questions or comments regarding 6.033? Send e-mail to the TAs at
6.033-tas@mit.edu.
Questions or comments about this web page? Send e-mail to
6.033-webmaster@mit.edu.
Top // 6.033 home // Last updated $Date: 2000/02/28 03:52:10 $ by $Author: sit $