indygreg added a comment.
We now send non-batchable commands immediately and wrap queued futures so
`result()` will trigger submission. This improves the end-user experience from:
with peer.commandexecutor() as e:
f = e.callcommand(...)
res = f.result()
to
with peer.commandexecutor() as e:
res = e.callcommand(...).result()
And in order to preserve streaming on batch responses:
with peer.commandexecutor() as e:
fs = []
for x in ...:
fs.append(...)
e.sendcommands()
for f in fs:
result = f.result()
to
with peer.commandexecutor() as e:
fs = []
for x in ...:
fs.append(e.callcommand(...))
for f in fs:
result = f.result()
This later improvement is because the first `result()` call on any returned
future will trigger submission of all queued commands. This also means we can
iterate or access the futures in any order. Of course, wire protocol version 1
will resolve them in the order they were issued. But this isn't necessarily
true about wire protocol version 2 :)
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D3267
To: indygreg, #hg-reviewers
Cc: mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
