Daniel Stenberg wrote:
> On Wed, 29 Sep 2004, Bertrand Demiddelaer wrote:
>
>>> I fail to understand how that is possible. Unless the connection is
>>> told to get closed, you don't call resolv_unlock() for that dns
>>> entry. Why isn't that entry then remaining locked?
>>
>>
>> That's exactly what I want: a resolv_unlock() call when the connection
>> is closed.
>
>
> That's what I want too. And that's why I think the resolv_unlock() call
> should be moved to Curl_disconnect() and called unconditionally from
> within it.
>
> Curl_disconnect() is called when the connection is to be disconnected.
> That happens after all requests are done on that connection.
>
> You made the call to resolv_unlock() conditional on a condition that may
> not happen and thus you may not unlock the dns_entry and therefor it
> might be left "locked". Do you agree or disagree with me on this analysis?
>
>> You are right to notice that a side effect of this new behaviour is
>> that entries in dns cache can remain valid longer,
>
>
> I don't have a problem with the entries being kept longer, I think it
> makes sense to have them kept while there are still live connections
> against the host.
>
>> they finally get pruned when every connection using them is closed.
>
>
> Only if the final request on that connection gets a "Connection: close",
> which you cannot be sure will happen.
>
> Or am I wrong?
>

It's ok.

I've been a bit quick with test cases and didn't check the case where
the server could close the socket without telling the client using
"Connection:" header.

Btw, my first attempt to put the code concerning dns cache update in
Curl_done() to Curl_disconnect() (basically copy-paste of the
'Curl_resolv_unlock() .... Curl_hostcache_prune()' section) had lead me
to a infinite hang in test 001 (any ideas on it ?). That was another of
the bad reasons which made me study the current patch.

Thanks for your patience...
Received on 2004-09-29