Augie Fackler wrote: > On Thu, Apr 13, 2017 at 3:55 PM, Augie Fackler <r...@durin42.com> wrote: > > On Wed, Mar 8, 2017 at 10:44 AM, Yuya Nishihara <y...@tcha.org> wrote: > >> On Tue, 7 Mar 2017 17:56:58 +0100, Pierre-Yves David wrote: > >>> On the other hand, this is probably not so bundle2 specific. We have > >>> some "select" logic to read stdout and stderr as soon as possible. This > >>> is the main suspect as it is possible that this logic behave different > >>> under linux and other unix (not too much effort have been put into it). > >> > >> posix.poll() waits every type of operation no matter if fd is e.g. writable > >> or not. IIRC, this doesn't always work on FreeBSD since the underlying > >> resource > >> of read/write ends might be shared in the kernel. > >> > >> But I don't think this is the source of the unstable output. > > > > I've had a little time today between things to try and debug this. > > What I've found so far: > > > > 1) when the test passes, the remote: output is printed by the > > _forwardoutput method in sshpeer, presumably since stderr makes it to > > the client before the close of stdout. > > 2) When the test fails (as on BSD, and I guess Solaris), the client > > notices that stdout closed before stderr. It then aborts the > > transaction and sshpeer.cleanup() notices some data chilling on stderr > > and ensures it gets read and printed. > > > > I'm not really sure why BSD systems would be quicker at communicating > > the closed FD than other systems. I'm poking at dummyssh now to see if > > maybe it's weirdness from there... > > Here's a patch that seems to work. I'm not happy about it, but it > makes the behavior consistent, and it looks mostly harmless.
Confirmed that it fixes the problem on Solaris, too. Thanks! Danek _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
