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:[EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users