From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27214 invoked by alias); 7 Jan 2015 17:57:38 -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 27202 invoked by uid 89); 7 Jan 2015 17:57:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout29.012.net.il Received: from mtaout29.012.net.il (HELO mtaout29.012.net.il) (80.179.55.185) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jan 2015 17:57:35 +0000 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NHT00D00ITH5I00@mtaout29.012.net.il> for gdb-patches@sourceware.org; Wed, 07 Jan 2015 19:54:30 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NHT0096KJ2Q3R50@mtaout29.012.net.il>; Wed, 07 Jan 2015 19:54:30 +0200 (IST) Date: Wed, 07 Jan 2015 17:57:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Speed up "gdb -tui" output In-reply-to: <54AD4E22.1010106@redhat.com> To: Pedro Alves Cc: dje@google.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83mw5u79t7.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00123.txt.bz2 > Date: Wed, 07 Jan 2015 15:17:54 +0000 > From: Pedro Alves > CC: gdb-patches > > > Reading symbols from foo...done. > > mumble ... > > (gdb) > > Since stdout is line buffered by default (on Unix), if this is > working when the TUI is disabled, then it must be because there's > explicit gdb_flush(gdb_stdout) after "Reading symbols from foo..." > is printed, right? Yes. > Isn't the issue then that the TUI's implementation of > gdb_flush (tui/tui-file.c) should be doing whatever it > needs to flush the output? Maybe. I already made that change in my sandbox. Alas, that's just the tip of the iceberg. We call single-character output functions, like putchar and fputc all over the place, implicitly assuming that in certain cases (e.g., when the stream is stderr), things are unbuffered and the output appears immediately. On top of that, functions that output strings go through single-character output versions, so there's no easy way of saying on, say, utils.c level whether the character should or shouldn't appear immediately. It's a terrible mess. > Should it be calling wrefresh if the file is gdb_stdout? Only if that stream is a real file, not a string or whatever else we support in ui-file. > If we do that, and change tui_puts like: > > - /* We could defer the following. */ > - wrefresh (w); > - fflush (stdout); > + if (c == '\n') > + gdb_flush (gdb_stdout); > > would it work? No, it's not enough. There's also gdb_stderr and gdb_stdlog, at least. (tui_puts doesn't get the stream as its argument, so it doesn't really know which stream it is serving.) I'm trying to make heads or tails out of this, but I'm not there yet.