On Mon, Nov 22, 2010 at 05:09:21PM -0800, Adam Light wrote:
> Thanks for the information. I have changed my application to set
> CURLOPT_NOSIGNAL to 1 and I have used --enable-threaded-resolver when
> configuring on Mac OSX. Is there any documentation for
> --enable-threaded-resolver? I am not sure how this is different from
> using c-ares. My preference would be to not use c-ares if there's not
> a strong reason to use it since that introduces another dependency in
> my project, but maybe I really need it and don't know it?

--enable-threaded-resolver is a fairly new option and it doesn't seem to
be very well documented (but see the FAQ). These are the various resolver
types available in libcurl with some of their disadvantages:

* Standard system resolver: Used by default. Uses some variant of
gethostbyname() or getaddrinfo(). Timeouts are handled with SIGALRM signal,
so CURLOPT_NOSIGNAL disables timeouts during resolve. Resolve timeout
causes the application context to switch to the signal handler, which is
very bad (i.e. can cause crashes) on some systems. Timeouts are limited
to 1 second granularity. Synchronous, so causes multi interface to block.

* c-ares asynchronous resolver: Uses the c-ares asynchronous resolver library.
Bypasses the system resolver entirely, so most system-specific resolver
configuration and plug-ins are ignored. No problems handling timeouts
on any system. Limited IPv6 support (this may no longer be true).

* Threaded resolver: Uses some variant of system's standard gethostbyname() or
getaddrinfo() function. Uses either pthreads or Windows threads (on Windows)
and creates one new thread per resolve. Non-blocking due to threads and has
no issues with timeouts. Threaded model means resource issues handling
hundreds or thousands of simultaneous connections (i.e. resolves).

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-23