Bulat Ziganshin wrote:
Hello Simon,
Friday, March 2, 2007, 1:07:07 PM, you wrote:
But let me add a voice to keeping the non-threaded RTS around.
i want to mention that problem here is not the threaded RTS by itself, but standard i/o library that works via separate i/o manager thread that is built-in part of RTS.
The I/O manager thread is hardly built-in to the RTS. It is all in a Haskell library; the only connection with the RTS is that the RTS feeds signals to the I/O manager thread down a pipe, and in fact we could move this signal-handling code out of the RTS and into the base package too. ? my Streams library [1] don't uses this thread
at all. for threads created with forkOS it provides excellent overlapping of I/O and computations (thanks, Simon, situation was *greatly* improved in 6.6). of course, it should be not so great for forkIO'd threads
I don't understand why forkOS should be any different from forkIO in this context. Could you explain? There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). Cheers, Simon