On Thu, Aug 24, 2006 at 01:12:32AM +0100, Frederik Eaton wrote:
> Do you think that the standard GHC behavior should be for
> multithreaded programs to produce garbage on stderr?
IIUC, even if you switch to LineBuffering on stderr, you'll still get
garbage, only less often and in more subtle ways, at least if we don't
go beyond what H98 guarantees:
line-buffering: the entire buffer is written out whenever a newline
is output, the buffer overflows, a flush is issued, or the handle
is closed.
As you can see, it is still possible that an incomplete line is written
when buffer overflows.
The safest solution is to make your logging code serialize the log
entries, using a mutex, a Chan or whatever - just what you did.
> C is different because it's not lazy. Usually small lines are printed
> to stderr; they fit in a single 'write' call and even if there are
> multiple such calls they usually happen within the same processor
> timeslice.
But this is nothing you can rely on. Of course, it can be enough for
simple logging.
> I think that in the GHC runtime, the default buffering mode for stderr
> should be line buffering (or perhaps, the same rules as for stdout
> should apply). I've modified my logging library to pre-evaluate
> strings with 'seq' and to use locking when writing messages to
> 'stderr', so it is no longer a problem for me personally; but for new
> users, for general-purpose use of the compiler, I think changing the
> stderr buffering mode is the best solution.
I seem to remember some people argued that switching stdout to
NoBuffering would make things easier for new users. Let's also change
stderr buffering mode, as you suggest. Now that's an ideal
configuration! ;-)
BTW, why didn't use simply change the buffering mode yourself?
Best regards
Tomasz
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
