This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Unbuffer stdout and stderr on windows


On Mon, Aug 12, 2013 at 02:11:05PM -0700, Joel Brobecker wrote:
>> We had a somewhat heated debate in the cygwin list about using the
>> techniques in winpty and eventually abandoned the idea because the way
>> things like winpty create consoles is not foolproof.  Since it relies on
>> polling, it is theoretically possible to lose data.
>> 
>> I'll bet that, in practice you'd never see any data loss, though.
>> And, from that observation, you can see which side of the argument
>> I was on.  :-)
>
>FWIW, many frontends also implements communication with GDB using
>pipes on Windows, and running MinGW-gdb inside cygwin window/shell
>is just a very very common practice, regardless of whether officially
>supported or not. How does Emacs do, for instance? IIRC when I looked
>at the code, that's what it did.
>
>Having the stdout/stderr output mixed up is very confusing and breaks
>testing as well, so we applied the same approach as Yao's at AdaCore.
>In the many many years that we've used this approach, no one ever
>complained to us about standard I/O performance.
>
>For completeness, our calls to setvbuf are inserted about 10 lines
>later, after gdb_stdout/gdb_stderr are set up.

So do you just unconditionally set gdb_std* to unbuffered?  I would
think that this would be nearly unnoticeable.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]