[PATCH] wireproto: explicitly flush stdio to prevent stalls on Windows

Matt Harbison mharbison72 at gmail.com
Sun Mar 11 15:58:02 EDT 2018


On Sun, 11 Mar 2018 05:43:13 -0400, Yuya Nishihara <yuya at tcha.org> wrote:

> On Sun, 11 Mar 2018 00:04:45 -0500, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at 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[1].  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').
>>
>> [1]  
>> 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.

Yep, fileobjectobserver flushes worked without this.  I've got no idea how  
this flush broke things free in the first place.  Maybe the server was  
waiting for more client requests, this gave it to the server, which then  
wrote enough more output to flush the server buffers?


More information about the Mercurial-devel mailing list