On Thu, 22 Apr 2004, Gisle Vanem wrote:

> > I also think we should provide a full Curl_getaddrinfo() function in
> > hostthre.c (instead of having it #ifdefed within hostip4.c) because then
> > hostip4.c will only have plain sync ipv4 resolve code.
>
> Same for hostip6.c too? Then there would be lots of duplicate code (check
> for AF_INET6 etc.) prior to calling Curl_init_resolve_thread() and
> getaddrinfo().

Here's how I imagine the threaded ipv4-version of the resolver would look
like. I agree that with this approach the CURL_IPRESOLVE_* and
CURL_INADDR_NONE checks need to be duplicated. I'll see if I can figure out a
way to keep them at a single place easier.

With this, we have four versions of Curl_getaddrinfo:

 * sync ipv4 (hostip4.c)
 * sync ipv6 (hostip6.c)
 * async ipv4 ares (hostares.c)
 * async ipv4 threaded (hostthre.c)

/*
 * Curl_getaddrinfo() - for Windows threading.
 */
Curl_addrinfo *Curl_getaddrinfo(struct connectdata *conn,
                                char *hostname,
                                int port,
                                int *waitp)
{
  in_addr_t in = inet_addr(hostname);

  *waitp = FALSE; /* default to synch response */

  if (in != CURL_INADDR_NONE)
    /* This is a dotted IP address 123.123.123.123-style */
    return Curl_ip2hostent(in, hostname);

  /* fire up a new resolver thread! */
  if (Curl_init_resolve_thread(conn, hostname, port)) {
    *waitp = TRUE; /* please wait for the response */
    return NULL;
  }
  infof(data, "Curl_init_resolve_thread() failed for %s; code %lu\n",
        hostname, GetLastError());

  return NULL;
}

Making this ipv6-enabled wouldn't add much complexity, afaics.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html