Re: [PATCH] Unbuffer stdout and stderr on windows

[Pedro Alves <palves@redhat.com>]

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