Thread (14 messages) flat view 14 messages, 6 authors, 2016-06-15

Re: What to expect after 0.99.8

From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:42:07

On Mon, 3 Oct 2005, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
The code in ssh-fetch already does parallel fetching, actually (only over 
one connection, but requests are sent before responses are read), so 
multiple requests are in progress at the same time.
This reminds me of one patch:

    From: Dan Aloni [off-list ref]
    Subject: [PATCH] Fix git+ssh's indefinite halts during long fetches
    Date: Sat, 1 Oct 2005 21:39:42 +0300
    Message-ID: <20051001183942.GA2099@localdomain>

I'd appreciate it if you had a chance to take a look at it and
comment on it.
I think it's overly hacky; we should be able, in prefetch, to check 
whether we've stuffed in a lot of hashes already, and actually read an 
object out before requesting another; there's nothing in the fetch 
contract that says that an object can't become available at some random 
time between the start of the fetch and when it gets requested with 
fetch(). (In fact, I had a pack-exchange version of the ssh stuff which 
would notice that you have certain things and you're looking for a commit, 
and get a bunch of stuff you probably want as a pack before you actually 
ask for it, but Linus beat me on that one with send-pack/upload-pack.)

I think that a limit of 100 objects in transit is about right, because the 
requests for 100 objects fits well within 4K and I expect that we 
commonly have small enough objects that we need to queue up a relatively 
large number of requests to maintain streaming.

I've got a patch, which I'll send in the next email.

	-Daniel
*This .sig left intentionally blank*
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help