Re: squid-3 comm reworking, pass 1

On Mon, 2006-09-18 at 15:18 +0800, Adrian Chadd wrote:

> * I'm going to sit down with Robert and think up a replacement
> method for doing the deferred reads. I don't believe the
> deferred reads logic belongs anywhere near the comm layer.
> I believe it should be something done at the StoreEntry/MemObject
> layer where there's enough information to determine when to
> schedule a comm read and how much.

In 2.6 there is two ways this works.

a) The store manager is maintaining a view of if the object should be
fetched or not.

b) The comm layer maintains the delay pools.

If it wasn't for delay pools then deferred reads could be taken out from
2.6 entirely, moving into on-demand reading instead.

Nothing stops delay pools from being redesigned in such manner that they
know which entries are being delayed, allowing for a better scheduling
of delayed objects without needing a deferred read.

Regards
Henrik
Received on Mon Sep 18 2006 - 03:15:32 MDT