From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29833 invoked by alias); 16 Aug 2013 13:37:30 -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 29824 invoked by uid 89); 16 Aug 2013 13:37:30 -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 13:37:30 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7GDbP1s001319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 09:37:25 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7GDbNtt002107; Fri, 16 Aug 2013 09:37:24 -0400 Message-ID: <520E2B13.8020706@redhat.com> Date: Fri, 16 Aug 2013 13:37: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: Yao Qi CC: gdb-patches@sourceware.org, brobecker@adacore.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> <520E1109.7000304@redhat.com> <520E1C34.2000907@codesourcery.com> In-Reply-To: <520E1C34.2000907@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00427.txt.bz2 On 08/16/2013 01:33 PM, Yao Qi wrote: > On 08/16/2013 07:46 PM, Pedro Alves wrote: >> 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. > > From this long discussion, people agree that stderr should be 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: > > However, we didn't have an agreement on what to set for stdout. As you > posted above, on Win32, stdout can be either full buffered or > non-buffered. If we change stdout to non-buffered, there are two > concerns, 1) GDB will slow down, 2) cause troubles to front-end, like Emacs. How can it cause trouble? If anything, it should be fully buffered that causes trouble (for output not coming out when it should). I really can't see when ever would it be desirable to hold GDB output until the internal buffer fills. So if GDB is supposed to be working when IO is fully buffered, some other mechanism must be forcing flushes on line ends (probably the gdb_flush calls). And then, if that is supposed to work, the testsuite really isn't special, and what we have is that the flushing mechanism isn't being activated in all the necessary places. -- Pedro Alves