Glynn Clements wrote:
Keean Schupke wrote:
Why is disk a special case?
With "slow" streams, where there may be an indefinite delay before the data is available, you can use non-blocking I/O, asynchronous I/O, select(), poll() etc to determine if the data is available. [...] With files or block devices, the data is always deemed to be "available", even if the data isn't in physical memory.
I don't think this really captures the reason for the difference. It's not that select chooses not to do anything on the assumption that file access is fast. It's that it /can't/ do anything, because (drum roll) disk files are totally different from streams. The data you read from an input stream is being actively written by someone else. As the producer keeps writing, data will end up buffered in local memory until you read it. select() tells you when there's buffered data to read. If you're reading from a random-access file, there's no way it can tell you when the file data is buffered, because it doesn't know which part of the file you plan to read. The OS may try to guess for readahead purposes, but select()'s behavior can't depend on that guess. If streams were distinguished from random-access files at the OS level, the situation would be different. The fact that you create an input stream on top of a disk file indicates to the OS that you plan to read the file sequentially from that point. It's natural to use the same buffering model that's used for sockets, and select() can tell you when that buffer is non-empty. This is just like readahead, except predictable and under app control to some extent. Since you can create an arbitrary number of streams on a file, this mechanism provides all the functionality of NT's overlapped I/O model and quite a bit more. This is another example of why the world would be better off with the file/stream model. Have I convinced anyone? -- Ben