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