From: Daniel Barkalow Date: Fri, 07 Oct 2005 22:39:22 GMT Subject: Re: [PATCH] Add support for parallel HTTP transfers Message-ID: In-Reply-To: <7vachl42tt.fsf@assigned-by-dhcp.cox.net> On Fri, 7 Oct 2005, Junio C Hamano wrote: > Nick Hengeveld 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*