4:12 AM
To flush a buffer is to cause pending operations to be performed. So, flushing an output buffer actually writes the data currently stored in it--and then the buffer is empty. Flushing an input buffer actually uses the data stored in it.
Flushing an output buffer is effectively always something that's done by the program writing output (usually as an automatic result of filling it all the way or of closing the file descriptor, but sometimes explicitly).
In contrast, flushing an input buffer is typically not done by the program reading input (and it is not universally clear what it would mean for a program to do that). The major example of forcing a flush on an input buffer that would not otherwise have occurred is when you press Ctrl+D in a terminal.
The asymmetry is because, to write buffered output, a program writes into a buffer until there is no room in the buffer (either it is full or another write needs to be done that would exceed its remaining space). Then it performs a write of the total number of bytes in the buffer. A library usually takes care of this, but it is still something that can be--and is--implemented in program logic.
In contrast, to read buffered input, a program attempts to read some number of bytes. If the read ought to complete before that number have been successfully read, that is not something the program can know or handle itself, because it does not know about that condition, because the read has not completed.
I've effectively described full buffering (block buffering). For example, the dd command performs buffered reads and writes. To specify the size of the buffer, you can use bs=, which stands for "block size." Otherwise a default of 512 bytes it used. It is not guaranteed that every read and write is of this size, because what if the size of the input file, or the output file, is not a multiple of that size? However, every write but the last (assuming all succeed) is of that size.
So, in full buffering (block buffering), an output buffer is flushed when it is full, when the file is closed, and when an explicit flush is performed. And an input buffer is flushed when it is full, and when reading succeeds but with fewer bytes than requested.
In line buffering, all that is the case. There is a buffer of some size, and it is flushed under those conditions. But it is also flushed when a newline is written or read. Thus, when a full line of output is ready (or the rest of a line, if it is longer than buffer size), the program flushed the buffer even if it's not full. And when a full line of input is ready, the read call completes even if there are fewer characters on the line than the number of bytes the program attempted to read.
@EliahKagan to read the next number
@EliahKagan There might be additional exceptions to this.
@EliahKagan Input in a terminal is line-buffered by default, which is why when you run cat with no arguments, you don't see what you've typed until you press Enter to send a newline or press Ctrl+D to force the buffer to be flushed.
There are multiple layers of buffering. If you call write, no application layer buffering will occur. If you look at the file from another process you will see the data, but that does not mean they have been committed to disk, because there is a layer of buffering happening in the kernel. Sinc...
