[PATCH] debugwireproto: handle unimplemented util.poll() for Windows

[Gregory Szorc]

On Mon, Mar 5, 2018 at 6:08 PM, Matt Harbison <mharbison72 at gmail.com> wrote:

> On Mon, 05 Mar 2018 20:58:23 -0500, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
>
> On Mon, Mar 5, 2018 at 5:48 PM, Matt Harbison <mharbison72 at gmail.com>
>> wrote:
>>
>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>> # Date 1520299354 18000
>>> #      Mon Mar 05 20:22:34 2018 -0500
>>> # Node ID 7a25f6cfebe80802321d2975b97fc15ec38cf8ec
>>> # Parent  2aff6daf779098eee4c350ccd0197dcc2231e197
>>> debugwireproto: handle unimplemented util.poll() for Windows
>>>
>>> This is the same logic used in sshpeer.doublepipe.  It doesn't completely
>>> fix
>>> test-ssh-proto{,-unbundle}.t ("read(-1) -> X" is changed to "read(X) ->
>>> X", the
>>> order of some lines are changed, and abort messages seem to be missing),
>>> but it
>>> cuts down a ton on the failure spew.
>>>
>>>
>> Queued.
>>
>> readavailable is intrinsically non-deterministic if there could be data on
>> both pipes. I think we should rewrite the tests to not use readavailable.
>>
>> This will likely require new commands in the metalanguage to read specific
>> amounts from specific pipes. That's probably the only way we make things
>> deterministic across platforms and various load conditions. I can author
>> those patches if you want, since I'm actively working in this area and I
>> did introduce the problem :)
>>
>
> Yes please :)  I can test if you don't have easy access to Windows.
>
> I'd like to get back to the lfs serving work (did you have any comments on
> V2?), but didn't want the decaying Windows tests to be hiding problems.  I
> looked at implementing util.poll(), but I don't think it's possible, at
> least without threads.  (WaitForMultipleObjects() doesn't take all types of
> handle.)
>

Sorry - I'm a bit behind on code review for things that weren't actively
discussed at the sprint.

We only use util.poll() in the ssh peer. I think it is safe to say that
handles will be pipes (whatever os.pipe creates) or process stdio handles.
Hopefully that makes things easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180305/ecef2de5/attachment.html>