On Thu, 16 Jan 2003, Jean-Philippe Barrette-LaPierre wrote:

> if you check Curl_resolv return a Curl_dns_entry *. The handle use this
> entry to connect to the remote site. The problem is that entry is contained
> by the global_dns_cache (if the handle use the global dns cache).

We're not actually talking about a global cache but a cache that is shared
between multiple handles. Not that big difference here of course.

> In the Curl_resolv thereis a function that delete the outdated entries.

Correct.

> At this time the library use inuse to verify that the entry is not used at
> the time we want to delete it.

Yes. 'inuse' is a counter that contains the number of users of that struct.

> The problem is that inuse is not thread-safe

Why is it not thread-safe? This is the key issue and I already asked you. I
claim that it *is* thread-safe if we make so.

> and I don't want to lock the mutex until we doesn't use a dns entry
> anymore.

Right, we don't have to lock the mutex until that, we only have to lock the
mutex when we fiddle with the inuse variable or does something like the
pruning. Until then we just simply READ the 'inuse' variable and unless it is
zero it is already in use.

Why is that a thread problem? Reading a variable is thread-safe.

Please, I'm aware that I might be thinking totally wrong here so I am
seriously asking you to tell me why we can't do it this way. I'm not seeing
the problem.

> It will cause a too big bottleneck to do that.

Locking all the time, yes. Locking when we need to, no. IMHO.

> At this time the sharing this for the mutex is just limited in the
> Curl_resolv, but if I need to lock the mutex until we don't use the
> dns_entry, I'll need to put implement the sharing thing in others functions
> that uses the dns_entry and that will be become very complicated, and the
> performence cost (because of the bottleneck) will be mutch higher that if
> we just copy the dns_entry.

Yes, it will force us to use the mutexes in a few more places than with your
solution (I haven't checked exactly how many), but we have no choice.

Duplicating the DNS data is awkward (if at all possible without depending on
existing implementations and protocols too much) and unecessary.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en