Re: client_side and comm_close

On Mon, 2008-04-21 at 01:11 +0200, Henrik Nordstrom wrote:
> 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..

Agreed. It looks like we are zeroing in on v3.1 solution for (b) and, in
part, (c):

- We are almost done defining comm_close API. We may be done if you
agree with my suggestion to make the close callback decide how it should
be called (with the old code-friendly default).

- We already know how to cancel pending I/O calls after comm_close.

- I hope we can avoid similar problems with comm_cancel_read because the
two or three places using that call can be adjusted to cancel the read
callback directly. We have already talked about that elsewhere.

Thank you,

Alex.
Received on Tue Apr 22 2008 - 13:03:43 MDT