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: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org, yao at codesourcery dot com, Eli Zaretskii <eliz at gnu dot org>
- Date: Mon, 12 Aug 2013 14:11:05 -0700
- Subject: Re: [PATCH] Unbuffer stdout and stderr on windows
- References: <1374462417-7961-1-git-send-email-yao at codesourcery dot com> <838v0yy556 dot fsf at gnu dot org> <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>
> 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.
--
Joel