Re: [PATCH] Unbuffer stdout and stderr on windows

[Pedro Alves <palves@redhat.com>]

On 08/16/2013 01:33 PM, Yao Qi wrote:
> On 08/16/2013 07:46 PM, Pedro Alves wrote:
>> However, the Windows runtime, in its infinite wisdom, makes stderr
>> fully buffered if connected to a pipe.
>>
>> So all this makes me very much question the desire to detect
>> if a native Win32 GDB is running under Cygwin.
>>
>> IMO, stderr should_always_  be forced to unbuffered.
> 
>  From this long discussion, people agree that stderr should be unbuffered.
> 
>>
>> 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.
>>
>> So I think the "in cygwin" detection is really not necessary
>> or desirable, and this patch should go back to its original form:
> 
> However, we didn't have an agreement on what to set for stdout.  As you 
> posted above, on Win32, stdout can be either full buffered or 
> non-buffered.  If we change stdout to non-buffered, there are two 
> concerns, 1) GDB will slow down, 2) cause troubles to front-end, like Emacs.

How can it cause trouble?  If anything, it should be fully buffered
that causes trouble (for output not coming out when it should).  I
really can't see when ever would it be desirable to hold GDB output
until the internal buffer fills.  So if GDB is supposed to be working when
IO is fully buffered, some other mechanism must be forcing flushes on
line ends (probably the gdb_flush calls).  And then, if that is supposed
to work, the testsuite really isn't special, and what we have is that
the flushing mechanism isn't being activated in all the necessary places.

-- 
Pedro Alves