On 02 December 2005 13:32, Joel Reymont wrote:

I was going on this quote by Simon PJ:

-- It should be find to have lots of threads, esp if most of them are asleep. The only thing to watch out for is that GHC's runtime system will consume one *OS* thread for each *blocked* foreign call. So if you have 10k threads each making a separate call to the OS to read from 10k sockets, and they all block, you'll use 10k OS threads, and that will probably fail. --

Is this correct and if so how does it mesh with what you said above?

It's correct, but not the whole story. When you do a blocking I/O operation, it is not implemented in terms of a blocking foreign call, so it doesn't create an OS thread(*). In -threaded mode, blocking I/O is implemented by sending a reguest to the I/O manager thread, which returns a response when I/O is available. In non-threaded mode, blocking I/O is implemented by returning to the runtime, which occasionally checks for available I/O and wakes up the appropraite threads. Either way, as I said, the programmer doesn't see any difference. (*) except on Windows, where everything is done differently and blocking I/O currently gets a real OS thread. Cheers, Simon