On Thu, 21 Mar 2002, Noel Byron wrote:

> > You focus too much on the DNS cache! ;-) I'm trying to set a generic
> > approach for all kinds of sharing between handles.
> >
> > The "global" DNS cache is a kind of violation of the whole libcurl
> > principle (global variables don't belong in library code), and as such it
> > must not be used as a (good) example when we discuss data sharing.
>
> Ok, now I think, I got it. If I want to 'simulate' global data such as the
> DNS cache I set the same cache for each CURL handle. And if somebody wants
> to use 3 CURL handles with cookie-jar A and another 4 CURL handles with jar
> B it remains possible.

Right.

> But I think this will be quite hard to implement with the CURLOPT_SHARE
> method. For example, somebody wants to to share the DNS cache (sorry)
> between all CURL handles. And he uses the one thread and CURL handle per
> download method. Every time he starts a thread (and builds a CURL handle)
> he has to know about al the other handles to share the ressource with them.
> This is not possible IMHO.

You're right, it might not be the most comfortable solution for that. I've
also thought about a few other cases which we should consider before deciding
on an interface. Imagine a case where we fire up three threads with three
handles to share cookies. As the cookies are "shared" between all three
handles no single one "owns" them. So what happens when we want to UNSHARE
one of the handles from another one? Also, should we allow that handle A
shares handle B, and then handle C shares handle A?

> If we want to do so, we must pass references (handles) of the resources out
> of libcURL. A client could for example obtain a handle to the DNS cache
> save it globally and pass it to every CURL handle. And such a ressource
> should be associated with a mutex.
>
> What do you think?

I like this.

This is more in the spirit of what I am leaning towards now too. Shared
resources have to be "extracted" from the handles. Or even created
separately, and then we connect specific handles to the those shared
"entities".

It also makes it a lot easier to understand where they (the shared entities)
belong.

I think we would need a new API to deal with these... Here's a first shot:

 share = curl_share_create(); /* create a "share" */

 curl_share_setopt(share, CURLSHARE_COOKIES, FALSE);
 curl_share_setopt(share, CURLSHARE_DNS, TRUE);
 curl_share_setopt(share, CURLSHARE_BIKESHED, TRUE);

 /* make an easy handle use the shared stuff */
 curl_easy_setopt(easy, CURLOPT_SHARE, share);

 /* stop using the shared data */
 curl_easy_setopt(easy, CURLOPT_UNSHARE, share);

 curl_share_destroy(share); /* no more shared data */

> > Yes, but the total running time will remain the same. You won't gain
> > anything by resolving the names prematurely, on the contrary, you only
> > risk that the info is bad when you eventually need/use it.
>
> May be I'm wrong but I think that the DNS cache stores hostname/ip pairs.
> And this mapping remains valid for hours. If you don't consider new economy
> companies. ;o)

I does occur that people move servers. www.foobar.com is not forced to always
use the same IP address...

So, if you cache the data for too long, the risk increases that you might get
into troubles. That's all I say.

> BTW if somebody knows how to do asynchronous DNS for all the other
> plattforms, I could contribute the windows stuff? :o)

If you define a good generic way, then there's no harm with starting to add
asynch name lookups on windows only.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/