Re: What to expect after 0.99.8

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 4, 2005, 07:31 UTC
Message-ID: <Pine.LNX.4.63.0510040321170.23242@iabervon.org>
In-Reply-To: <20051004071210.GA18716@localdomain>

On Tue, 4 Oct 2005, Dan Aloni wrote:

Show 33 quoted lines

> On Mon, Oct 03, 2005 at 04:16:27PM -0700, Linus Torvalds wrote:
> > 
> > 
> > On Mon, 3 Oct 2005, Junio C Hamano wrote:
> > > 
> > > This reminds me of one patch:
> > > 
> > >     From: Dan Aloni <da-x@monatomic.org>
> > >     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 personally hate it.
> > 
> > It adds horrible patches to fairly core stuff, all because the prefetching 
> > is not limited.
> 
> Well it can be reworked to be more clean...
>  
> > As far as I can tell, it should be much easier to just limit the 
> > prefetching to some reasonable limit (say, a few objects deep), which 
> > guarantees that the prefetching doesn't fill up the write queues on the 
> > fetching side.
> 
> I'm not sure how this will be completely reliable, even if you limit the
> prefetching to one object.
> 
> Suppose that this one object's size is larger than the receiving queues of 
> the receiving end (like 1 MB?) and the bandwidth is high, wouldn't that 
> break?

It shouldn't cause any problem, unless there isn't a 4K buffer between the git-ssh-fetch and ssh; the fetch side would have to fill this buffer before getting stuck, even if ssh can't send out any more data until the object has been read, and 100 requests (each 21 bytes) wouldn't be enough. I remember that there's a lot that depends on being able to put 4K into an empty pipe without blocking, and I'd guess that UNIX sockets have a similar capacity (although I'm not going to look it up tonight).

	-Daniel
*This .sig left intentionally blank*