Re: client_side and comm_close

From: Henrik Nordstrom <henrik@dont-contact.us>
Date: Mon, 21 Apr 2008 01:11:44 +0200

sön 2008-04-20 klockan 22:29 +0300 skrev Tsantilas Christos:
> I am not saying that all are OK with the comm_close. Looks that there is
> a problem with this function, and this is the second problem....
>
> This why I am saying that there are two different problems here....

There is actually three distinct problems discussed...

a) client_side* is a big tangled mess beyond any repair, broken by
design and patched around too many times, making it very fragile each
time touched.

b) comm is unable to cancel pending calls from comm_ calls using
callback pointers (callers not using AsyncCall) when asked to (either
explicit such as comm_read_cancel, or implicit by comm_close). Basically
an AsyncCall migration API issue with no caller/receiver boundary for
the AsyncCall. I haven't looked into how things works out then the
caller of comm_* givest the AsyncCall object, but at least then it's
possible for that comm_* caller to cancel the call..

c) comm_close now async, while some of the code really expects it to be
synchronous allowing for immediate teardown of everything related..

The first is just what it is. A big ugly mess of code which been around
for too long. Somewhat cleaned up in Squid-3, but still battling with
the fundamental design issues of the environment where the code
operates...

The second is a plain bug imho. The open question is if the bug is to be
fixed, or if it can be eleminated by converting everything over to
AsyncCall...

The last is a reality in the current code, but probably not a desired
property of the code..

Regards
Henrik
Received on Tue Apr 22 2008 - 13:17:38 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT