On 19 January 2005 20:31, Glynn Clements wrote:
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.
We're getting a bit confused here. Keean: the original question was about whether a disk read will stop all other *Haskell* threads. Not OS threads. The two are quite different beasts in GHC. Cheers, Simon
Simon Marlow wrote:
We're getting a bit confused here. Keean: the original question was about whether a disk read will stop all other *Haskell* threads. Not OS threads. The two are quite different beasts in GHC.
Cheers, Simon
But if GHC is running with the -threaded flag, then other Haskell-threads can keep running using the second OS-thread, even though one Haskell-thread (and its associated OS thread) is blocking - right? In other words even with disk IO (as I said the kernel would not busy-wait - so there are only two options, this OS-thread is put to sleep, or the data is already in a buffer and is returned immediately), all the other Haskell-threads should not block (provided it is running with -threaded) Have I got that right? Keean.
participants (2)
-
Keean Schupke -
Simon Marlow