[Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions

[Ben Rudiak-Gould]

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