This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Unbuffer stdout and stderr on windows
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org, brobecker at adacore dot com, yao at codesourcery dot com
- Date: Fri, 16 Aug 2013 14:30:20 +0100
- Subject: Re: [PATCH] Unbuffer stdout and stderr on windows
- References: <51EE23F8 dot 1070905 at codesourcery dot com> <83wqohw4ee dot fsf at gnu dot org> <20130729192559 dot GA5348 at ednor dot casa dot cgf dot cx> <83d2q1xiyv dot fsf at gnu dot org> <51F6C7B2 dot 3020400 at redhat dot com> <20130731034045 dot GA5565 at ednor dot casa dot cgf dot cx> <20130812211105 dot GA11128 at adacore dot com> <8361v9piop dot fsf at gnu dot org> <20130815173618 dot GA6955 at ednor dot casa dot cgf dot cx> <83eh9uonlg dot fsf at gnu dot org> <20130815175940 dot GD6955 at ednor dot casa dot cgf dot cx> <520E1109 dot 7000304 at redhat dot com> <83y581n5ag dot fsf at gnu dot org>
On 08/16/2013 02:17 PM, Eli Zaretskii wrote:
>> Date: Fri, 16 Aug 2013 12:46:17 +0100
>> From: Pedro Alves <palves@redhat.com>
>>
>> IMO, stderr should _always_ be forced to unbuffered.
>
> We are in agreement about stderr. The issue is with stdout.
OK.
>> I can't really imagine that leaving stdout fully buffered to
>> ever be good (which the cygwin detection seems to want to preserve),
>> even for frontends, given GDB is an interactive program, and even
>> MI is text/line based.
>
> If the choice is between fully buffered stdout and unbuffered stdout,
> I prefer the former for performance reasons.
>
>> So I think the "in cygwin" detection is really not necessary
>> or desirable, and this patch should go back to its original form:
...
> Sorry, I disagree. No one has ever complained about the current
> buffering of stdout on Windows. The issue that is the subject of this
> thread is a problem that happens in running the test suite. I firmly
> believe in the principle of not fixing that which isn't broken.
So how is emacs starting GDB? Because if it is starting GDB
in a console, then nobody's complaining because output is already
not buffered. If it is started in a pipe, then what is
forcing flushing at line ends so that emacs doesn't break?
IOW, the testsuite is not special, in that if emacs starts
GDB with io connected to pipes, then it should be having the
exact same issues the testsuite has. In that case, hacking
the issue _only_ when running the testsuite actually masks
out a real problem. We do have "gdb_flush (gdb_stdout)" calls
sprinkled through the tree. If that is what makes emacs+pipe work,
then OK, we can remain with stdout fully buffered, but then I'd say
that the bug is that there are places that miss gdb_flush calls.
--
Pedro Alves