Re: [PATCH] Speed up "gdb -tui" output

[Doug Evans <dje@google.com>]

On Wed, Jan 7, 2015 at 10:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Jan 2015 10:09:03 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: Pedro Alves <palves@redhat.com>, gdb-patches <gdb-patches@sourceware.org>
>>
>> >> 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
>
> That's not really true, as you yourself point out:
>
>> Though I see tui also has its own ui file strings (tui_sfileopen).
>> That can go I think.
>
> I don't see how it could go: it's used.

Can't it be replaced with mem_fileopen?
Maybe I'm missing something.

>> >> 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.
>
> How else can you emulate the unbuffered nature of gdb_stderr and the
> line-buffered nature of gdb_stdout, for example?  The GDB application
> code implicitly expects that.

If one wants to restrict the problem to just gdb_stderr vs gdb_stdout
(which is insufficient, since gdb_stdout gets unfiltered output),
but for discussion's sake ...
The tui to_puts method, tui_file_fputs, knows what the stream is.