Re: client_side and comm_close

tor 2008-04-17 klockan 20:13 +0300 skrev Tsantilas Christos:

> As I can understand the problem does not exist only in squid3.0 or only
> in squid3-trunk.

The problems show up mainly in squid3-trunk due to the delays introduced
by AsyncCalls, combined with the inability for old code to cancel
pending operations when needed where they could do so just fine before
AsyncCalls... The client_side_* and pconn* code isn't designed to deal
with this kind of asyncness..

> The main problem with the client_side code is that the comm_read done by
> the ConnStateData class, the comm_writes by the ClientSocketContext
> class and comm_close (and other comm operations ) by all. This makes
> very difficult to manage the comm related problems in client_side code....

Yes, but before AsyncCalls it all wound down immediately on comm_close,
cancelling all further operations. The FD got closed, the
ClientSocketContext invalidate and pending requests cancelled. So while
this code is pretty much the same in 3-trunk it's only a problem after
the introduction of AsyncCalls.

The AsyncCalls do solve another class of problems however, what has been
referred to as "recursion" in this thread. Or to be specific the
combined fact that comm_close was immediate and that it wasn't always
obvious when comm_close would trigger in complex code where comm_close
is called from multiple places or deep down in processing chains where
the upper layers maybe assumes it won't get called.

This "recursion" only existed for comm_close, not read/write or timed
events as those always bounced via the event loop before called.

Regards
Henrik
Received on Tue Apr 22 2008 - 14:20:30 MDT