From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8338 invoked by alias); 5 Mar 2019 17:54:32 -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 8321 invoked by uid 89); 5 Mar 2019 17:54:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pty X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Mar 2019 17:54:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 366E61179B0; Tue, 5 Mar 2019 12:54:29 -0500 (EST) 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 talp02k9-NxA; Tue, 5 Mar 2019 12:54:29 -0500 (EST) Received: from murgatroyd (75-166-85-218.hlrn.qwest.net [75.166.85.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id B4134116A88; Tue, 5 Mar 2019 12:54:28 -0500 (EST) From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH] Remove excess calls to gdb_flush References: <20190219205426.4168-1-tromey@adacore.com> <63a71432-2cd2-cde9-0f27-0115f795334c@redhat.com> Date: Tue, 05 Mar 2019 17:54:00 -0000 In-Reply-To: <63a71432-2cd2-cde9-0f27-0115f795334c@redhat.com> (Pedro Alves's message of "Tue, 5 Mar 2019 17:06:31 +0000") Message-ID: <87k1hdtdf0.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-03/txt/msg00059.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> On 02/19/2019 08:54 PM, Tom Tromey wrote: >> >> my belief being that gdb's standard output >> streams are line buffered (by inheriting the behavior from stdio) Pedro> That's only true if gdb is connected to a pty. If gdb is started with Pedro> a pipe or regular file for stdout/stderr instead, then it won't be. I Pedro> guess we could fix that with a setvbuf call at startup though. I'll take a look. Tom