Re: Tidying up the deferred reads

On Fri, Oct 14, 2005, Henrik Nordstrom wrote:

> I however think I prefer the comm layer being the main responsible for the
> deferrals. This ensures it's done in the same manner for all the
> protocols, and allows for less race conditions I think..
>
> But ultimately there would be no need for deferrals at all, and this whole
> thing being maintained by the store layer pulling data from the protocols
> (or the client in uploads) rather than the protocols "blindly" pushing
> data into the store. This however requires a fair bit or restructuring to
> get it right. But maybe this is sort of what you are doing?

Thats the eventual aim of what I'm doing. Thats a pretty big step from the
existing 2.5 (and 3.0 code if I read it right) and thus what I have at the
moment is more of a 'middle ground' between the current server pushing and
the more desirable store-oriented fetching.

It wouldn't actually require that much more restructuring from where my
code is at right now. You need to have a 'free-running' store side
to read the reply and process headers but once the body is being transferred
the code should switch to using STKICK_FETCH (which, eventually, will mean
"register for one IO event only and don't re-register after completion.")

Are others interested in this? I don't think it should strictly go into
squid-2.5 because its quite a large rework. If its worth placing into a release
squid, and I believe the kqueue/epoll support and throughput increase alone
should justify it, maybe .. squid-2.6?

*duck*

adrian
Received on Fri Oct 14 2005 - 19:58:57 MDT