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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
