Re: [PATCH] Add support for parallel HTTP transfers

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 7, 2005, 22:39 UTC
Message-ID: <Pine.LNX.4.63.0510071808071.23242@iabervon.org>
In-Reply-To: <7vachl42tt.fsf@assigned-by-dhcp.cox.net>

On Fri, 7 Oct 2005, Junio C Hamano wrote:

Show 14 quoted lines

> Nick Hengeveld <nickh@reactrix.com> writes:
> 
> > I think the only downside to leaving that check in place is that when
> > pull() finishes there may be completed requests left behind in the
> > queue, possibly with unreported transfer errors.  Would it make sense
> > to just release any requests left in the queue after pull(), and report
> > if any of them had transfer errors?
> 
> Pull finishing and reporting success while some requests have
> still been outstanding with transfer errors sounds to me that
> decision to finish and declare success is made prematurely.
> What do these leftover requests you are worried about ask for?
> Are you making redundant requests, which can turn out to be
> unneeded?

I believe that the situation is the one you describe in your previous message: we determine we need to fetch A and B; we ask for A; we ask for B; we find A isn't available alone, but is available in a pack; we get the pack; we find we now have B (in the pack); the request for B (which would probably fail) is left dangling.

The only actual problem I can see is if this happens with a whole bunch of objects at the beginning of a big download, and all but one of your connections are left in this state while you download all of the loose objects over the one connection that got the pack.

I don't know if this is a problem for the new http code, but it could be an issue in general if a transport method allocates resources in prefetch().

	-Daniel
*This .sig left intentionally blank*