From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVR94-0005aJ-2w for qemu-devel@nongnu.org; Mon, 27 Jul 2009 10:25:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVR8x-0005Xf-Dx for qemu-devel@nongnu.org; Mon, 27 Jul 2009 10:25:40 -0400 Received: from [199.232.76.173] (port=51757 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVR8w-0005XT-EK for qemu-devel@nongnu.org; Mon, 27 Jul 2009 10:25:34 -0400 Received: from mail-ew0-f217.google.com ([209.85.219.217]:35966) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVR8v-0002j9-Tc for qemu-devel@nongnu.org; Mon, 27 Jul 2009 10:25:34 -0400 Received: by ewy17 with SMTP id 17so3151759ewy.34 for ; Mon, 27 Jul 2009 07:25:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20090727134208.GA3803@caradoc.them.org> References: <20090727132123.GA2428@caradoc.them.org> <5b31733c0907270633xb49d83we1858a6e9ba45d63@mail.gmail.com> <20090727134208.GA3803@caradoc.them.org> Date: Mon, 27 Jul 2009 16:25:32 +0200 Message-ID: <5b31733c0907270725y715098dcl8221e5de2e62995c@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 3/5] Remove setvbuf(, NULL, _IOLBF, 0) calls for Win32 From: Filip Navara Content-Type: multipart/alternative; boundary=0016e6dab6d708de08046fb0ba88 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel Jacobowitz Cc: qemu-devel@nongnu.org --0016e6dab6d708de08046fb0ba88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jul 27, 2009 at 3:42 PM, Daniel Jacobowitz 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 > 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 --0016e6dab6d708de08046fb0ba88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 27, 2009 at 3:42 PM, Daniel Jacobowi= tz <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 a= nd that's not supported on Win32 anyway, conditionally remove them.
> >
> > Should they be unbuffered where _IOLBF is not supported, then? = =A0I
> > assume the line buffering was to make them more useful in event o= f 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 usefu= l to
> me.

I've found that leaving stdout buffered on Windows is a pai= n; on Unix
"isatty()" is reliable, but on Windows it breaks down at the
Cygwin/Windows interaction border. =A0So 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 Q= EMU in regular command line and MSYS sh and I never had a single problem wi= th the buffering. I can't speak for Cygwin, but if they can't get i= t 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) !=3D 0").

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

Best regards,
Filip Navara
--0016e6dab6d708de08046fb0ba88--