On Mon, 19 Mar 2007, Sebastien Trottier wrote:

> I'm sure the problems we reported don't apply to the synchronous or c-ares
> resolvers, but we need
> a) an asynchronous interface to be able to trigger multiple transfers at the
> same time (ie without the calling thread being blocked by gethostbyname())
> and
> b) to resolve hostnames from the same sources as the win32 gethostbyname(),
> ie including WINS name resolution, as we have a lot of customers that don't
> maintain local DNS servers, and I understand c-ares deals with DNS only.

Then I guess we need to find a fix for this problem... or improve c-ares! ;-)

> There are already locks around the cache using a share is used: the problem
> is the sharing of the multi cache between easy handles coupled with the
> threaded resolver. I saw that there are changes in terms of cache sharing in
> 7.16.1 compared to the 7.15.4 version we're using. Are easy handles still
> sharing their cache via the multi by default?

Yes, and with 7.16.* there's even more sharing by default within multi
handles.

> In my mind, a share should be explicitly used, and mutexes provided, by a
> client that wants to share its hostname resolution results between easy
> handles when using the threaded resolver; no sharing should be performed
> when using default compile flags (threaded resolver) and the multi interface
> without a share on win32.

The problem here is the threaded resolver, not the sharing of data, if you ask
me. Perhaps we could somehow set a default set of lock/unlock functions for
for the multi shared DNS cache when a threaded resolver is used?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html