David Roundy wrote:
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.
But surely it does! read only reads the next block... to skip randomly you must seek... therefore the following sequence does this:
seek select read
The select should block until one disk block from the file is in memory, read is defined such that it will return if some data is ready even if it is not as much as you requested. So in this case if you ask for a complete file, you may just get one block... or more.
In other words the API restricts reads to the 'next' block - so seek knows which block needs to be read into memory...
Wouldn't select always fail, since the block would never be read into memory until you call read?
True, unless calling select() automatically triggered read-ahead
(which isn't an unreasonable idea).
In that regard, select/poll is different from non-blocking and
asynchronous I/O. With the latter, you're explicitly asking for data
to be read.
--
Glynn Clements