ghci and ghc -threaded broken with pipes & forking
simonmarhaskell at gmail.com
Mon Mar 5 07:59:17 EST 2007
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  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).
More information about the Glasgow-haskell-users