trying to understand rationale of unix stream i/o concept
I am an entry level programmer with no formal training in computer science. I am trying to enhance my conceptual knowledge about operating systems in general.
I have been using the C programming language on Linux systems for some time and have used the traditional unix stream I/O APIs. The introductory material in books and on the web, typically introduce the unix stream I/O model as "basic unix I/O model is a stream of bytes which can be accessed sequentially or randomly". I understand this part, but I am unable to visualize how else would one access the data. Were the I/O models different before the I/O stream model came in to existence? Are there models in current computing paradigm which are different from the stream I/O. I will appreciate if some can help me visualize both the stream I/O model vs other models (if they exist or existed). Pros-Cons will be a great addition too.
In addition, I came across the following statement on the web (I/O System)
"The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially. There are no access methods and no control blocks in a typical UNIX user process."
I do not understand the last statement - what are access methods and control blocks in the context of I/O?
A method is like a subroutine. An example might be a file of dictionary words. Instead of writing. you "insert" the word. Somehow the system keeps the words in alphabetical order. You can retrieve a list of all word in alphabetical order or you can search for a word. But the data file itself is a black box and you can't access it. If you put 1,234 bytes worth of words into the data file it will be bigger than 1,234 bytes. The system needs some extra stuff to find it's way around the file. This extra stuff is the control blocks.
And believe it or not, there used to be a sequential file which behaved like a really stupid tape drive. You could read it. You could even read it byte-by-byte. But after you read, say, byte number 123, you had two choices: read byte 124 or close the file. However, the OS could predict a program's behavior rather easily and this was fast (for it's day).
There might be a "random" file where you could seek and then read, but it was slow. After seeking to byte 123 and reading one byte, you could next seek to byte 124 and read that. But if you wanted a sequential file, you were supposed use a sequential file, not a random file.
Mind you, a single data file might be opened as "sequential" by one program and "random" by another. But then each program had a different interface (or subroutine or method) to read the file. However there was no way to execute a data file or to read a program file.
There were many file types and OS's competed by offering more file types. The Unix model of just one file type displaced all of this.