Tidying up the deferred reads

Hi everyone,

I've found a little time recently to implement an idea I had
for removing the deferred reads from squid. These things in 2.5
are one of the things I've found my squids spend a bit of time in.
Removing them lets me unwind the repeated building of
the poll/select list every time through comm_select().

This is all being done with squid-2.5 because that is what the
current live proxy caches here at work run.

What I've done in a nutshell is added in a little 'hinting'
which the store and store client participate in. The store server
(in the current case, only src/http.c) registers a callback
which is called to either 'start' or 'stop' the IO flow.
'stop' is called whenever the store side is too far ahead from
all the store clients when storeAppend() is called.
'start' is called whenever the client side storeClientCopy3()
ends up being unable to fulfill reading data (either from memory
or from disk) which starts the IO up again.

Initial tests with just the HTTP code when pushed with datacomm-1
are promising. I'm a little worried about any error conditions that
might occur. I handle the case where the callback changes (and I've
seen it happen a few times whenever I forcibly end polyclt/polysrv
to simulate errors) but things seem to be working just fine.

I'd like some feedback please. If it works out my plan is to
replace the FTP, WAIS and Gopher (eww) code with this.
The SSL code will need a little more thought as it doesn't pass
through fwdCheckDeferRead() like the others. clientReadDefer()
and httpAcceptDefer() can be 'redone' with registered events like
I did a few years ago in my earlier attempts to push this stuff
through. The changes shouldn't be too intrusive.

Thanks!

Adrian
Received on Sun Oct 09 2005 - 10:34:20 MDT