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
