On Fri, 2005-01-21 at 12:33 +0000, Keean Schupke wrote:
Glynn Clements wrote:
The central issue is that the Unix API doesn't distinguish between
cases 1 and 2 when it comes to non-blocking I/O, asynchronous I/O, select/poll etc. [OTOH, NT overlapped I/O and certain Unix extensions do distinguish these cases, i.e. data is only "available" when it's in physical RAM.]
This is in direct contradiction to the documentation for select. Select specifically says it returns if a handle in the read list would _not_ block on a read call.
The point is that the Unix documentation does not consider the short pause as data is read off your hard drive to be blocking. So that's why select will always report that data is available when you use it with a file handle. It considers blocking only to be pauses of indefinite length like you can get when reading from pipes or sockets. Since in that case you depend on the writer end getting round to giving you more data, whereas the kernel considers data in a file to be always available. Of course as people have pointed out this is not a terribly helpful assumption for slow devices and does not allow overlapping IO with processing. The only way to get that is to use other OS APIs dedicated to async/overlapped IO or to use OS threads. Duncan