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

Reply via email to