From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10895 invoked by alias); 12 Aug 2013 21:11:10 -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 10875 invoked by uid 89); 12 Aug 2013 21:11:10 -0000 X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_40,RCVD_IN_HOSTKARMA_NO autolearn=ham version=3.3.2 Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 12 Aug 2013 21:11:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 180E31160D3; Mon, 12 Aug 2013 17:11:10 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FTEst7h0Bld8; Mon, 12 Aug 2013 17:11:10 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B1F591160CD; Mon, 12 Aug 2013 17:11:09 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5A53EC1B82; Mon, 12 Aug 2013 14:11:05 -0700 (PDT) Date: Mon, 12 Aug 2013 21:11:00 -0000 From: Joel Brobecker To: Pedro Alves , gdb-patches@sourceware.org, yao@codesourcery.com, Eli Zaretskii Subject: Re: [PATCH] Unbuffer stdout and stderr on windows Message-ID: <20130812211105.GA11128@adacore.com> References: <1374462417-7961-1-git-send-email-yao@codesourcery.com> <838v0yy556.fsf@gnu.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130731034045.GA5565@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-08/txt/msg00324.txt.bz2 > We had a somewhat heated debate in the cygwin list about using the > techniques in winpty and eventually abandoned the idea because the way > things like winpty create consoles is not foolproof. Since it relies on > polling, it is theoretically possible to lose data. > > I'll bet that, in practice you'd never see any data loss, though. > And, from that observation, you can see which side of the argument > I was on. :-) FWIW, many frontends also implements communication with GDB using pipes on Windows, and running MinGW-gdb inside cygwin window/shell is just a very very common practice, regardless of whether officially supported or not. How does Emacs do, for instance? IIRC when I looked at the code, that's what it did. Having the stdout/stderr output mixed up is very confusing and breaks testing as well, so we applied the same approach as Yao's at AdaCore. In the many many years that we've used this approach, no one ever complained to us about standard I/O performance. For completeness, our calls to setvbuf are inserted about 10 lines later, after gdb_stdout/gdb_stderr are set up. -- Joel