Re: [PATCH] mingw: make stderr unbuffered again
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 16, 2017, 17:10 UTC
- Message-ID
- <alpine.DEB.2.20.1702161753050.3496@virtualbox>
- In-Reply-To
- <0275af7b-eb7a-1094-a891-674300175e56@kdbg.org>
Hi Hannes,
On Wed, 15 Feb 2017, Johannes Sixt wrote:
Show 24 quoted lines
> Am 15.02.2017 um 13:32 schrieb Johannes Schindelin: > > On Tue, 14 Feb 2017, Johannes Sixt wrote: > > > Am 14.02.2017 um 15:47 schrieb Johannes Schindelin: > > > > On Mon, 13 Feb 2017, Junio C Hamano wrote: > > > > > Johannes Schindelin <johannes.schindelin@gmx.de> writes: > > > > > > What we forgot was to mark stderr as unbuffered again. > > > > > > I do not see how the earlier patch turned stderr from unbuffered to > > > buffered, as it did not add or remove any setvbuf() call. Can you > > > explain? > > > > [ motivation and history of js/mingw-isatty snipped ] > > > > So instead of "bending" the target HANDLE of the existing > > stdout/stderr (which would *naturally* have kept the > > buffered/unbuffered nature as-is), we now redirect with correct API > > calls. > > Your statement implies that at the time when winansi_init() begins, > stdio is already initialized and the buffered/unbuffered state has been > set for stderr. I would think that this is true. > > Then we swap out the file handle underlying stderr in swap_osfhnd() > using dup2(). Why would that change the buffered state of stdio?
The file handle we swap in for stderr points to the pipe that a freshly-started thread consumes for parsing the ANSI color sequences. This handle is used both for stdout and stderr. The dup2() call then implicitly reopens stderr, with the default buffering.
Show 9 quoted lines
> > And the patch I provided at the bottom of this mail thread reinstates > > the unbuffered nature of stderr now that it gets reopened. > > > > Hopefully that makes it clear why the setvbuf() call is required now, > > but was previously unnecessary? > > Unfortunately, no. I do not see how dup2() causes a change in stdio state. I > must be missing something (and that may be a basic misunderstanding of how > stdio is initialized).
It appears that dup2()ing fd 2 resets that stdio state.
Ciao, Dscho