From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1712 invoked by alias); 7 Jan 2015 18:09:07 -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 1699 invoked by uid 89); 7 Jan 2015 18:09:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 07 Jan 2015 18:09:05 +0000 Received: by mail-oi0-f41.google.com with SMTP id i138so4014615oig.0 for ; Wed, 07 Jan 2015 10:09:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SYTMVOYo9IHbMe7zGN3BiEGgYqsiJdUt6z6f7mvowyU=; b=GMfv0NguFtMo3FgxO8MCE4zuEWZlK9SIlvwua5gIE/0wwGODIC5WJz/2hC3rqaRnGz oTZMDsHFTxCxSpob42bUUqzIgm243ysv6Ut91x99VdmWojf6YbIg/t/c8If1G6i8QpJu QQgKswBk+ZKGI6GQn5AXDKkaWha0X/Qoq6uEukRG/nztke82I42/a1DvcsUpIbrd6wPl 79nyLBvGbMDqqS5H1PFoiUBqpKu13lTSFEWckRW/iP+cMvfSCuAomaM3uWDf9Jn7qYJ4 bCtkhpPZLyi6hYciueElNMJHtRmIiyNDioE7fjo6kC456mpJynxXUiRVYtFjK4Pvxw1i quBQ== X-Gm-Message-State: ALoCoQmSDytVFKjW33PFO4Z1UKS8DEv6iskrHnE+B87UTbwirfz0oj+HCmj8PeTfOeWiJl1cPNI4 MIME-Version: 1.0 X-Received: by 10.182.234.15 with SMTP id ua15mr2809852obc.77.1420654143535; Wed, 07 Jan 2015 10:09:03 -0800 (PST) Received: by 10.182.222.98 with HTTP; Wed, 7 Jan 2015 10:09:03 -0800 (PST) In-Reply-To: <83mw5u79t7.fsf@gnu.org> References: <83zj9v7urq.fsf@gnu.org> <54AD4E22.1010106@redhat.com> <83mw5u79t7.fsf@gnu.org> Date: Wed, 07 Jan 2015 18:09:00 -0000 Message-ID: Subject: Re: [PATCH] Speed up "gdb -tui" output From: Doug Evans To: Eli Zaretskii Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00125.txt.bz2 On Wed, Jan 7, 2015 at 9:57 AM, Eli Zaretskii wrote: >> 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. tui_file_flush only gets called for tui files, so no worries there. Though I see tui also has its own ui file strings (tui_sfileopen). That can go I think. > >> 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. Sure, but it does suggest tui_puts is the wrong place to do any kind of flushing/refreshing. Fortunately, tui_puts is internal to tui.