RE: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
On 19 January 2005 09:45, 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?
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
(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.)
I don't think that description corresponds with the implementation, but then I'm not terribly familiar with that part of the code. It doesn't get used when -threaded is on. Cheers, Simon
On 19 January 2005 09:45, Ben Rudiak-Gould wrote:
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?
On Wed, Jan 19, 2005 at 01:39:05PM -0000, Simon Marlow wrote:
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
How does forkOS fit into this picture? It's described in the documentation as allowing concurrent execution of system calls and other activity by other threads. -- wli
Simon Marlow wrote:
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?
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
I think this is not true on linux, where a thread is just a process created with special flags to keep the same fds and memory. As threads on linux are scheduled like processes, one thread blocking should not affect the others? (As an alternative there is always the AIO library) Keean.
Keean Schupke wrote:
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?
It's true on Unix-like systems, I believe. Even with -threaded. It might not be true on Win32.
I think this is not true on linux, where a thread is just a process created with special flags to keep the same fds and memory.
As threads on linux are scheduled like processes, one thread blocking should not affect the others?
That should be true of all POSIX-like thread implementations
(including Linux, whose threads aren't quite POSIX-compliant, e.g. in
regard to signal handling, but aren't that far off).
Essentially, blocking system calls only block the calling kernel
thread.
OTOH, if you are implementing multiple user-space threads within a
single kernel thread, if that kernel thread blocks, all of the
user-space threads within it will be blocked.
--
Glynn Clements
participants (4)
-
Glynn Clements -
Keean Schupke -
Simon Marlow -
William Lee Irwin III