On Sun, 11 Mar 2018 08:55:41 -0400, Matt Harbison wrote:
> > On Mar 11, 2018, at 5:43 AM, Yuya Nishihara <y...@tcha.org> wrote:
> >> On Sun, 11 Mar 2018 00:04:45 -0500, Matt Harbison wrote:
> >> # HG changeset patch
> >> # User Matt Harbison <matt_harbi...@yahoo.com>
> >> # Date 1520744281 18000
> >> # Sat Mar 10 23:58:01 2018 -0500
> >> # Node ID 1145671119a40e82932f63f83ad4049727416174
> >> # Parent 963b4223d14fa419df2a82fbe47cd55075707b6a
> >> wireproto: explicitly flush stdio to prevent stalls on Windows
> >> This is the key to fixing the hangs on Windows in D2720. I put flushes
> >> in a
> >> bunch of other places that didn't help, but I suspect that's more a lack
> >> of test
> >> coverage than anything else.
> >> Chasing down stuff like this is pretty painful. I'm wondering if we can
> >> put a
> >> proxy around sys.stderr (and sys.stdout?) on Windows (only when
> >> daemonized?)
> >> that will flush on every write (or at least every write with a '\n').
> >> 
> >> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-March/113352.html
> >> diff --git a/mercurial/debugcommands.py b/mercurial/debugcommands.py
> >> --- a/mercurial/debugcommands.py
> >> +++ b/mercurial/debugcommands.py
> >> @@ -2769,6 +2769,8 @@ def debugwireproto(ui, repo, **opts):
> >> # Now perform actions based on the parsed wire language instructions.
> >> for action, lines in blocks:
> >> + util.stdout.flush()
> > This one is suspicious. Can you clarify which data is flushed? I think
> > fileobjectobserver should flush log per method call.
> Yeah, this made no sense to me. I would have expected that it needed to be
> flushed on the server side. But, here’s where it stalls without this:
Ok, if the server stalls, that might be because of the --noreadstderr option.
The client must read stderr so the server can write into the pipe.
Mercurial-devel mailing list