Re: [Qemu-devel] [PATCH 3/5] Remove setvbuf(<handle>, NULL, _IOLBF, 0) calls for Win32

[Filip Navara <filip.navara@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On Mon, Jul 27, 2009 at 3:42 PM, Daniel Jacobowitz <drow@false.org> wrote:

> On Mon, Jul 27, 2009 at 03:33:08PM +0200, Filip Navara wrote:
> > On Mon, Jul 27, 2009 at 3:21 PM, Daniel Jacobowitz<drow@false.org>
> wrote:
> > > On Mon, Jul 27, 2009 at 10:02:04AM +0000, Filip Navara wrote:
> > >> On Win32 the setvbuf function requires the last parameter to be size
> between 2 and INT_MAX bytes, so the calls always failed. Since the whole
> point of the calls is to set line-buffered mode for the file handle and
> that's not supported on Win32 anyway, conditionally remove them.
> > >
> > > Should they be unbuffered where _IOLBF is not supported, then?  I
> > > assume the line buffering was to make them more useful in event of a
> > > crash.
> >
> > I guess your assumption is correct. I'd be fine with using _IONBF for
> > the exec.c part, but setting it for stdout doesn't sound too useful to
> > me.
>
> I've found that leaving stdout buffered on Windows is a pain; on Unix
> "isatty()" is reliable, but on Windows it breaks down at the
> Cygwin/Windows interaction border.  So your simulated programs end up
> using block output all the time if you have a mingw32 qemu in a Cygwin
> terminal, for instance.


I use MinGW-built QEMU in regular command line and MSYS sh and I never had a
single problem with the buffering. I can't speak for Cygwin, but if they
can't get it right I don't think it's up to QEMU to fix it (heck, checking
for a console handle is as easy as "(handle & 3) != 0").

The log files are different story, since for certain types of crashes the
last block is lost. Since log files are actually used for debugging problems
I acknowledge that keeping the content is important.

Best regards,
Filip Navara

[-- Attachment #2: Type: text/html, Size: 2274 bytes --]