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