[Webkit-unassigned] [Bug 27165] Connections-per-host should be tracked closer to the ResourceHandle level, not the Cache

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 23 03:24:16 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=27165





--- Comment #21 from Adam Barth <abarth at webkit.org>  2010-09-23 03:24:15 PST ---
> Reading the comments above, it was clearly known that this is patch could change behavior in poorly understood ways. That's not good, especially for refactoring patches.

The fact that no one understands the loader is certainly a problem for the project.  Hopefully we'll be able to improve the design to make it more understandable.

> The design looks good as far as pictures of boxes go, though obviously it doesn't really capture the real complexity of the loading subsystem.

Definitely.  Drawing that picture was more of a high-level organizational roadmap.

> I think this patch could be fixed by reverting the changes to Loader, expect for those that are directly related to moving counting of connections to the new class. The OpenConnectionLimiter should probably also signal Loader when there are more slots available (this is currently achieved by calling Loader::nonCacheRequestComplete() from random places).

That sounds reasonable.

> Still, I'm not sure that keeping per-host data in two places (Loader::Host map for queues, OpenConnectionLimiter for the count) instead of one is an improvement. Perhaps we should move most of the Loader::Host to the ResourceLoader level instead?

I certainly think it makes sense to decouple prioritization concerns from caching concerns.  It's possible we should put these concerns in a layer above ResourceLoader but below the current next layer.  In a sense, that would be generalizing Loader to handle more of the loading subsystem, which I think is the direction you mentioned above.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list