ghci and ghc -threaded broken with pipes & forking

Bulat Ziganshin bulat.ziganshin at gmail.com
Mon Mar 5 15:10:08 EST 2007


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 :)

i remember that i had problems with forkIO. i will try it again and
report results

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Glasgow-haskell-users mailing list