From: Keith M. <kei...@us...> - 2011-02-22 17:04:04
|
On 22 February 2011 15:14, Andy Koppe wrote: > On 22 February 2011 15:01, Keith Marshall wrote: >> On 22 February 2011 13:54, Albrecht Schlosser wrote: >>> Instead of using flush, it is also possible to set stdout and stderr >>> unbuffered unconditionally at program initialization: >>> >>> setvbuf (stdout,NULL,_IONBF,0); >>> setvbuf (stderr,NULL,_IONBF,0); > > _IOLBF ought to do the job too, except that according to MSDN "For > some systems, this provides line buffering. However, for Win32, the > behavior is the same as _IOFBF - Full Buffering." :( So, yet another example of "broken windows" behaviour. :-) >>> While we're at it (slightly OT): mingw-get suffers from this I/O >>> buffering problem when run inside mintty. Could you imagine to >>> "repair" this by using one of the techniques described above? >> >> I guess I could, but first I'd like to understand why it should be >> necessary. The buffering issue normally only arises for interactive >> programs, which mingw-get is not. Regardless of buffering mode, all of >> mingw-get's output, (mostly to stderr), should be flushed at program >> termination. > > It is, but the issue is nevertheless noticeable with long-running > operations, in particular downloads. Since the output is only flushed > when the buffer (with 512 bytes?) gets full, you only get an update > every ten lines or so. AFAICT, the ISO C Standard insists that stderr shall *not* be fully buffered, when opened. Ever. (That is, irrespective of whether it is connected to a terminal or otherwise). Thus, it might be unbuffered, or it might be line buffered, but it should never be fully buffered. Okay, Windows apparently does not have any concept of line buffered (IOLBF) output, so that means, for standards conformance[*] stderr should never be anything other than unbuffered; yet it appears that it becomes fully buffered when connected to a pipe. Bad, bad Microsoft. Score minus 100 for conformance. [*] Of course, we all know Microsoft's "embrace and extend" attitude to standards conformance: "embrace" = squeeze it into a black hole void of irrelevance; "extend" = then do just whatever the h*** they like. > Thanks for considering this. Since the only standards conforming way which Windows appears to offer, for the handling of stderr, is to make it unbuffered, perhaps I should just "fix" the Microsoft "breakage" up-front, with a call to setvbuf; I hope it won't have any seriously detrimental effect on performance. Alternatively, an explicit flush in dmh_printf might achieve a similar effect, with less impact on performance. -- Regards, Keith. |