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