RE: [Haskell-cafe] Re: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
On 19 January 2005 16:49, Keean Schupke wrote:
But what about the continuing computation... we do not want the fastest IO system, but we want the program to comlete the fastest... So ideally we want 2 threads!
One runs the Haskell code that is not waiting for IO. (IE other Haskell threads)... The other runs a select loop as you suggest!
This way the number of threads is fixed (2) and execution never 'blocks' for IO. (Simon, what about this scheme?)
This is what GHC does, if I understand you correctly. The thread running select() does so in its own OS thread, while another OS thread runs the Haskell code. As long as you use -threaded, that is. Oh, and before GHC 6.4 it was done a different way - the scheduler used to do the select() between running Haskell threads. Cheers, Simon
Simon Marlow wrote:
On 19 January 2005 16:49, Keean Schupke wrote:
But what about the continuing computation... we do not want the fastest IO system, but we want the program to comlete the fastest... So ideally we want 2 threads!
One runs the Haskell code that is not waiting for IO. (IE other Haskell threads)... The other runs a select loop as you suggest!
This way the number of threads is fixed (2) and execution never 'blocks' for IO. (Simon, what about this scheme?)
This is what GHC does, if I understand you correctly. The thread running select() does so in its own OS thread, while another OS thread runs the Haskell code. As long as you use -threaded, that is. Oh, and before GHC 6.4 it was done a different way - the scheduler used to do the select() between running Haskell threads.
Cheers, Simon
So this means even though the IO calls block, the other Haskell threads (when run with -threaded) keep running? Keean.
participants (2)
-
Keean Schupke -
Simon Marlow