The idea is that putStrLn iterates putChar over the String, then putChar '\n'; so thread scheduling would be more obvious with individual characters being output instead of a single flush triggered by the final putChar.
> ... try flushing stdout within the forked thread,
I did. The behaviour is still as described:
depends on -O0/2, [no]omit-yield,
and small changes in the source.
While I agree with the general point -
why would I need to hFlush after putStrLn?
hGetBuffering stdout tells me it's LineBuffering,
and putStrLn does write a line?
- J.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
--