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