ghci and ghc -threaded broken with pipes & forking

[Simon Marlow]

Bulat Ziganshin wrote:
> Hello Simon,
> 
> Monday, March 5, 2007, 3:59:17 PM, you wrote:
> 
>>> 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).
> 
> it may be entirely due my ignorance :)  my program anyway uses
> -threaded and forkOS in order to run several C threads si,ultaneously
> and i don't performed tests in any other conditions
> 
> so, one thread may read data from file, another thread write data and
> one more make compression using C routine. in 6.4, these tasks was
> overlapped only partially while in 6.6 they 100% overlap
> 
> don't forget that read/write calls are also foreign calls, so while
> all C calls are marked as "safe", 6.4 doesn't overlap them good
> enough (also, to make things harder, C compression routine makes calls
> back to the Haskell routines). if haskell runtime will create new
> threads for executing other Haskell threads while one thread performs
> safe C call, then it should be ok. probably, i just mixed up forkOs
> and -threaded mode :)

Ok, there was a complete rewrite of the scheduler between 6.4 and 6.6 so this 
may account for the differences you see.

Beware of forkOS: it'll reduce performance on the Haskell side, because 
essentially each context switch between a forkOS'd thread and another thread is 
a complete OS-thread context switch, which is hundreds of times slower than 
context switching between forkIO'd threads.

Cheers,
	Simon