On Fri, 2008-04-18 at 16:15 +0800, Adrian Chadd wrote: > On Wed, Apr 16, 2008, Alex Rousskov wrote: > > > In short, we have several related problems here: (a) client_side code is > > incapable of reliably identifying whether comm_close has been called; > > (b) ConnStateData::isOpen may not work anymore; (c) client_side code > > uses many different ways to identify whether more data should be read > > from the connection; (d) comm_close is used a lot but no longer has an > > immediate effect and some client_side code may still depend on that > > effect to be immediate; (e) client_side comm handlers decent very deep, > > making it difficult to propagate errors and comm_close status up. > > > > We should decide whether to continue patching holes here and there or > > clean up the client_side*cc connection management mess for good. Should > > we continue to patch isolated v3.0 problems and cleanup v3.1? Or is this > > a v3.2 project? Or am I exaggerating the problems since common cases > > usually work fine? > > I'd suggest another option - roll back all of the async calls changes to the > comm code, stabilise the codebase without it and re-evaluate what should > occur (in smaller chunks, rather than dropping in a new comm manager) > before reintroducing it.
If the client_side's main problem was a few coding bugs caused by async call changes, you may have been right. Unfortunately, our main problem here is the client_side design flaws. Removing async calls from comm will not undo those flaws. The changes needed on the client-side are pretty much unrelated to async calls. Async calls just make the design problems more obvious and help in solving them. Removing async calls from comm will fix a few bugs, but will be a step backwards and will make ongoing code cleanup more difficult. Another way to look at it is to note that client_side was already pretty stable before async calls (i.e., Squid 3.0). Thus, we have already been where you are proposing to go. Alex.