Re: [PATCH] Add support for parallel HTTP transfers

On Fri, 2005-10-07 at 17:39, Daniel Barkalow wrote:

> 
> 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().

So, this sounds like a classic resource scheduling problem
with various solutions encoded in many compiler schedulers.

Doesn't this sort of scheduling problem get solved by a
two-stage request pipeline model?  In particular, you only
"semi-request A" and "semi-request B" into a queue.  When
all of the sub-parts (that are needed) of some pack P have
been requested you issue the one request for the common
pack P holding all the sub-parts.  Then all the sub-parts
are can be retired from the queue.

Or am I just now finally catching up? :-)

Thanks,
jdl


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html