Udo Stenzel wrote:
The Glibc documentation says, "select determines if there is data available (more precisely, if a call to read(2) will not block)." I think, this is reasonably precise. The OS does know, where you are going to read (at the file pointer) and if you seek() or pread() instead, well, that is no call to read(2) and may change everything.
Thus the question is, does select() reliably tell if read() would block or does it check for something else? Is the documentation wrong (on some platforms)?
Having read around I have found that select does return readable for all file IO on a block device... I wonder if ghc could use non-blocking mode (files opened with the O_NONBLOCK) flag? In which case you just do the read, and it returns immediately with the current contents of the buffer (up to the size in the read argument)... The sheduler could allow one chance at reading, then give the other haskell-threads a go whilst more data comes in. Keean.