On Sunday 22 June 2003 12.25, Robert Collins wrote:
I'm seeing duplicate pconnDelete's occuring in HEAD. in might be new (as I've only noticed it since the recent change in pconn semantics), or it may be older...
just a heads up, I'm hoping to fix it tonight regardless.
I don't think it is related to the recent change as all this did was to extend the pconn hash key where needed (i.e. when talking to a originserver class peer).
However, the last return in pconnPop looks a bit dubious.. should be a "return -1;" I think...
I'll review that.
I think I've tracked it down - it's old.
The 2.5 and before comms reading was synchronous - no callbacks within squid.
The 3.0 comms reads are asynchronous, but we don't cbdata lock the callback data.
This leads to (many) races. This particular one is when pconnDelete frees an a connection description (due to 0 fd's available), and a pconnRead was outstanding on it..
Rob
