On 20 January 2005 09:56, Keean Schupke wrote:
Why is disk a special case? I have never heard that all processes under linux wait for a disk read...
You were talking about Haskell threads, not processes! These are quite different things.
The kernel most certainly does not busy wait for disks to respond, so the only alternative is that the process that needs to wait (and only that process) is put to sleep. In which case a second thread would be unaffected.
Linux does not busy wait in the Kernel! (don't forget the kernel does read-ahead, so it could be that read really does return 'immediately' and without any delay apart from at the end of file - In which case asynchronous IO just slows you down with extra context switches).
The question is whether Haskell threads block when one of them is reading from the disk, and this has nothing to do with what happens in the kernel. I never said that Linux busy waits in the kernel. The reason that disk I/O is different is because select() treats it differently, and select() is what GHC's runtime currently uses to multiplex I/O. Cheers, Simon
Simon Marlow wrote:
On 20 January 2005 09:56, Keean Schupke wrote:
Why is disk a special case? I have never heard that all processes under linux wait for a disk read...
You were talking about Haskell threads, not processes! These are quite different things.
But with -threaded GHC is using multiple processes (OS-threads) to run the Haskell threads. If one OS thread handles IO, and the other runs the Haskell-thread-scheduler, then Haskell-threads need never wait for IO - apart form the actual thread doing the IO.
The reason that disk I/O is different is because select() treats it differently, and select() is what GHC's runtime currently uses to multiplex I/O.
Are you sure? Its not mentioned in the manual... Keean.
participants (2)
-
Keean Schupke -
Simon Marlow