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. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
