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