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

[Keean Schupke]

Nonblocking (asynchronous IO) is only one solution. Another is to use 
blocking IO and
multiple threads. Each thread represents an IO dependency, in other 
words there is no
point in a thread doing IO continuing because it needs the data it is 
waiting for. Unassociated
threads do not get blocked and carry on. Threading has the advantage of 
using multiple
CPUs if available - asynchronous IO does not do this. With the advent of 
multi-cored CPUs
(due to heat problems CPUs will not be getting much faster in terms of 
raw GHz) threading
is obviously the way forward.

GHC already supports multiple threads (with the -threaded flag I think) 
... where FFI actions
are started in their own thread... Of course there are overheads with 
starting threads, so
normally applications maintain a 'thread-pool' of ready to use, 
pre-initialised threads... I don't
know if GHC does this.

    Keean.

Ben Rudiak-Gould wrote:

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