From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22488 invoked by alias); 16 Aug 2013 11:46:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22473 invoked by uid 89); 16 Aug 2013 11:46:27 -0000 X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 16 Aug 2013 11:46:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7GBkKct002248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 07:46:20 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7GBkHhn006468; Fri, 16 Aug 2013 07:46:18 -0400 Message-ID: <520E1109.7000304@redhat.com> Date: Fri, 16 Aug 2013 11:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: palves@redhat.com, gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com, Eli Zaretskii Subject: Re: [PATCH] Unbuffer stdout and stderr on windows References: <51EE23F8.1070905@codesourcery.com> <83wqohw4ee.fsf@gnu.org> <20130729192559.GA5348@ednor.casa.cgf.cx> <83d2q1xiyv.fsf@gnu.org> <51F6C7B2.3020400@redhat.com> <20130731034045.GA5565@ednor.casa.cgf.cx> <20130812211105.GA11128@adacore.com> <8361v9piop.fsf@gnu.org> <20130815173618.GA6955@ednor.casa.cgf.cx> <83eh9uonlg.fsf@gnu.org> <20130815175940.GD6955@ednor.casa.cgf.cx> In-Reply-To: <20130815175940.GD6955@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00422.txt.bz2 Sorry for chiming in so late... On 08/15/2013 06:59 PM, Christopher Faylor wrote: > On Thu, Aug 15, 2013 at 08:44:43PM +0300, Eli Zaretskii wrote: >> On Thu, 15 Aug 2013 13:36:18 -0400, Christopher Faylor wrote: >>> I thought that "unbuffered" normally means something like "every output >>> operation gets immediately sent as a block" rather than "flush after >>> every character". >> >> AFAIK, unbuffered always meant the latter. >> >>> If the mingw "unbuffered" mode means that everything is o n e c h a r a >>> c t e r a t a t i m e >> >> It does mean that. Doesn't it work like that in Cygwin? > > Cygwin uses newlib which, AFAICT, writes a block at a time without > storing the block in a buffer first. > > So: > > fwrite (foo, 27, 1, stdout); > > writes 27 bytes to stdout in one shot, without buffering. > > I only got this from looking at the code so I could be wrong. > >>> The other alternative would be to use line buffering for gdb. I don't >>> see why cygwin pipes (whether they are "ptys" or actual pipes) are a >>> special case here. stdout is usually line buffered isn't it? Why not >>> just force that behavior for gdb? >> >> That's what I suggested, but Yao says that using line buffering still >> fails some tests. > > Sorry, I missed that you'd already suggested that. Quoting that part of previous discussion: On 08/01/2013 09:05 AM, Yao Qi wrote: > On 07/29/2013 11:42 PM, Eli Zaretskii wrote: >>>> + setvbuf (stdout, NULL, _IONBF, BUFSIZ); >>>> + setvbuf (stderr, NULL, _IONBF, BUFSIZ); >> How about using line buffering instead on both streams? Or at least >> leave stdout line-buffered? Did you try that, and if so, did that >> have the same problems that triggered these patches? > > I tried line-buffering for stdout, but get some regressions in python > related testing, That's because there's no such thing as line-buffering on Windows. See _IOLBF For some systems, this provides line buffering. However, for Win32, the behavior is the same as _IOFBF - Full Buffering. Also, ISO C (C99/TC3/N1256, 7.19.3 Files, point 7) says: "As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device." Note that stderr might be either unbuffered or line buffered, but _never_ fully buffered. And most implementations default to leaving stderr always unbuffered (so that error output comes out immediately). However, the Windows runtime, in its infinite wisdom, makes stderr fully buffered if connected to a pipe. So all this makes me very much question the desire to detect if a native Win32 GDB is running under Cygwin. IMO, stderr should _always_ be forced to unbuffered. I can't really imagine that leaving stdout fully buffered to ever be good (which the cygwin detection seems to want to preserve), even for frontends, given GDB is an interactive program, and even MI is text/line based. So I think the "in cygwin" detection is really not necessary or desirable, and this patch should go back to its original form: +#ifdef _WIN32 + /* A Cygwin ssh session may not look like a terminal to the Windows + runtime; ensure unbuffered output. */ + setvbuf (stdout, NULL, _IONBF, BUFSIZ); + setvbuf (stderr, NULL, _IONBF, BUFSIZ); +#endif -- Pedro Alves