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.