Hiya, Here's the first part of my comm reworking for squid-3.
http://www.creative.net.au/diffs/20060918-squid3-comm-7.diff I've created another(!) array holding the read/write callbacks for comm_read and comm_write. I've deleted the CommWrite path and converted comm_read and comm_write into C paths rather than C++ paths. I've run through and unified the calls to comm_write and comm_old_write. This code deletes the need to constantly be creating/destroying temporary read state and io callbacks (and I'll do the same for the connect path shortly.) This code does look like a step back, but here's my eventual aim: * I'm aiming to bring the rest of the comm code back into C. I don't believe any of the abstractions (save the deferred reads abstraction) is actually buying us anything in the comm codebase. I'll leave the deferred manager how it is but convert it over to using comm_read() and delete the old-style IO callback list. * 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. * I'll then sit back with the clean code and slowly convert all of this mess into something resembling a C++ API, but only after we've all had a little more experience (and squid-3 is out the door and stable!) with an eye for the future. Why? I don't believe the current abstractions to be useful. Noone has really made any real push to use alternative network/ communication layers which don't provide Berkeley sockets and file descriptors. The real way to do this is to properly abstract out everything beginning at the filedescriptor layer and allow people to drop in replacement "fd", IPC, comm and disk implementations of a fixed API. This would be nice to have in the future. The C API, with perhaps enough fruit to support stuff like the Callback type, should do us fine for now. Its entirely possible my view here will change once this code has been written but I really think the comm layer needs to be tidied up and made as efficient as possible before we attempt to make things "better". A drian
