ghci and ghc -threaded broken with pipes & forking
Simon Marlow
simonmarhaskell at gmail.com
Tue Mar 6 05:52:14 EST 2007
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
More information about the Glasgow-haskell-users
mailing list