Re: Endangered I/O operations

Carl R. Witty writes:

"Simon Marlow" writes:

...

You obtain the ordering properties by setting the handle to NoBuffering, otherwise you get buffered input/output. Wouldn't it be deviating from the report to do extra flushing in the buffered case? (this is something of a technicality, actually we already do non-report flushing in several cases and our line-buffered input isn't line-buffered at all).

If the report does not allow the implementation to flush buffers at any time, I would call that a bug in the report. I would much rather use an implementation where stdout and stderr came out in the right order, and reading from stdin flushed stdout. (As another example, an implementation might want to flush all buffers before doing a fork(), to avoid duplicated output.)

A related wish I have is that a Haskell program receiving a HUP signal should flush its buffers before terminating. Or even better, flush on some other signal that does not terminate the program. I frequently have long-running (weeks, months ...) applications that produce data (lists) with decreasing speed. Since data may be sitting in unflushed buffers for days (weeks, ...), I currently shy away from using Show instances for lists and instead use the following ``printList'' function:

hPutList :: String -> (a -> ShowS) -> Handle -> [a] -> IO () hPutList sep shows h = mapM_ f where f x = hPutStr h (shows x sep) >> hFlush h

putList :: String -> (a -> ShowS) -> [a] -> IO () putList sep shows = hPutList sep shows stdout

printList :: Show a => String -> [a] -> IO () printList sep = putList sep shows

It would be really nice to have other possibilities to force the program to flush buffers! Cheers, Wolfram