ghci and ghc -threaded broken with pipes & forking

[Simon Marlow]

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