Re: client_side and comm_close

On Sat, 2008-04-19 at 10:50 +0800, Adrian Chadd wrote:
> On Fri, Apr 18, 2008, Alex Rousskov wrote:

> > 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.
>
> I know this.

> > 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.
>
> But now you have a better understanding of the bugs that are introduced
> with AsyncCalls. You can then plan design changes to the client-side code
> to work around these.

I am not sure how to rephrase this so that it is clear, but client-side
design changes are needed to fix client-side bugs, not to work around
AsyncCall bugs. AsyncCalls are just a helpful tool here, not the focus.
Removing AsyncCalls will not help but will hurt.

I simply do not understand why you focus on AsyncCalls in the context of
this thread when this thread discusses client-side problems that were
there before AsyncCalls and are there after AsyncCalls were added.

> > 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.
>
> Yes, then you left it by introducing something which exposed the bugs.

The problems this thread is discussing were known before AsyncCalls.

> Its great that we now know about the bugs - but now you've got a codebase
> that you're trying to stabilise

This thread is not about stabilizing client-side code. It is about
changing its key classes and the relationships among them (for many
reasons). This will certainly destabilize the code short-term. If it
would not, I would not need to ask others opinion whether we should wait
with that work!

> and you can't guarantee you understand
> all of the possible ways its going to break in the future.

True. In fact, nobody can "guarantee he understands all of the possible
ways something is going to break in the future".

> If you back out the async related changes then you'll have a stable codebase
> again - you can then make smaller incremental changes to the codebase
> and test them to make sure you haven't broken anything, rather than spending
> possibly 6 + months finding more surprises.

I do not think we can fix the problems discussed here by doing small
incremental changes. We are not talking about bug workarounds or a few
places that need internal polishing.

> Remember, the initial idea was to use 3.1 to tidy up the codebase to stabilise
> it, not tidy up the codebase to unstabilise it. Redesigning chunks of the
> comm codebase -was- on my todo list for 3.1, but then people dumped stuff into
> 3 to make it less stable again.

This thread is not about redesigning comm APIs, and I do not know much
about your todo list, but Squid 3.1 roadmap has been built in public. If
any proposed Squid 3.1 features went against your plans, you should have
added your feature(s) to the roadmap and discussed conflicts. This
procedure does not guarantee anything (those who work together on the
project have to compromise), but it works better than complaining about
the first steps while approaching the end of the road.

And nobody is tidying up the code to make it unstable, obviously.

In summary, I do not understand how removing AsyncCalls would help fix
client-side design problems that are the subject of this thread. I do
not even understand why we are talking about AsyncCalls here.

Alex.
Received on Tue Apr 22 2008 - 12:43:37 MDT