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

[Ben Rudiak-Gould]

Glynn Clements wrote:

 >Ben Rudiak-Gould wrote:
 >
 >>GHC really needs non-blocking
 >>I/O to support its thread model, and memory-mapped I/O always blocks.
 >
 >If, by "blocks", you mean that execution will be suspended until the
 >data has been read from the device into the buffer cache, then Unix
 >non-blocking I/O (i.e. O_NONBLOCK) also blocks.

Okay, my ignorance of Posix is showing again. Is it currently the case, 
then, that every GHC thread will stop running while a disk read is in 
progress in any thread? Is this true on all platforms?

There are two ways of reading from a file/stream in Win32 on NT. One is 
asynchronous: the call returns immediately and you receive a 
notification later that the read has completed. The other is synchronous 
but almost-nonblocking: it returns as much data as is "available", and 
the entire contents of a file is considered always available. But it 
always returns at least one byte, and may spend an arbitrary amount of 
time waiting for that first byte. You can avoid this by waiting for the 
handle to become signalled; if it's signalled then a subsequent ReadFile 
will not block indefinitely.

Win32's synchronous ReadFile is basically the same as Posix's (blocking) 
read. For some reason I thought that Win32's asynchronous ReadFile was 
similar to Posix's non-blocking read, but I gather from [1] that they're 
completely different.

(By the way, are the GHC folks aware that the description of Win32 I/O 
at [2] is wrong? It seems to assume that ReadFile doesn't return until 
the buffer is full.)

-- Ben

[1] http://www.opengroup.org/onlinepubs/007908799/xsh/read.html
[2] 
http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/non-blocking.html