Duncan Coutts <[EMAIL PROTECTED]> writes: > 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.
Isn't this also for historic reasons? I.e. disk latency has improved from what? 20ms to perhaps 7ms the last fifteen years. CPU frequency has gone from a few MHz to a few GHz in the same time frame. So while a disk seek used to amount to perhaps a thousand instructions -- hardly worth a task switch, it now amounts to millions of instructions. (All numbers made up, of course) With fast CPUs and distributed memory (NUMA architectures), the difference between cache and global memory is beginning to increase also -- perhaps select() really should wake up when the buffer is available in L2 cache? -kzm -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
