[Haskell-cafe] Re: Hugs
vs GHC (again)was: Re: Somerandomnewbiequestions
Benjamin.Rudiak-Gould at cl.cam.ac.uk
Wed Jan 19 04:45:03 EST 2005
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  that they're
(By the way, are the GHC folks aware that the description of Win32 I/O
at  is wrong? It seems to assume that ReadFile doesn't return until
the buffer is full.)
More information about the Haskell-Cafe