Re: IdleConnList problems

On 05/07/11 06:35, Tsantilas Christos wrote:
> Hi all,
> I am still having many problems with IdleConnList :-(
>
> Looks that the IdleConnList::pop() and the IdleConnList::findUseable()
> methods return always NULL.
> The reason is the fd_table[]::flags.read_pending flag which is always 0.
> I can find only one place in the code where this flag set to 1/true, and
> this is in ssl/support.cc file inside ssl_read_method function.
>
> The test:
> if (!fd_table[theList_[i]->fd].flags.read_pending)
> continue;
> replaced an older check which used the comm_has_pending_read_callback
> function which returned always false.
>
> What is the fde::flags::read_pending flag? What is supposed to do?

The docs say it indicates whether the FD has a read event/call scheduled
but not yet dialed.
  For idle conns that means the conn is about to close and is unsafe for
use.

>
> Just removing the check for fd_table[].flags.read_pending in pop and
> findUsable methods I am getting other assertions when trying to set a
> comm-read handler on a connections retrieved from the connections pool. ...

According to the docs around the non-working
comm_has_pending_read_callback() it was supposed to return true whenever
a read handler callback was scheduled but not yet handled.
  That never actually worked.

The quick fix is to drop that read_pending tests from idle conn
handling. We are no more likely to hit the race conditions now with it
broken as we are without it.

On the side; read_pending and write_pending both seem to be special case
flags, used for weird stuff unrelated to their documentation.

Long term I think we should rename them to state what they actually do.
Then implement wholly new read_pending/write_pending as a count of
events pending a dial() to match the current documented meanings.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.9