On Sat, Dec 17, 2011 at 9:33 PM, Pedro Larroy
<pedro.larroy.lists_at_gmail.com>wrote:

> Hi
>
> After some flustration with blocking on dns requests while using the
> multi interface with libevent (https://github.com/larroy/mycelium) I
> investigated how curl uses ares and I came to the conclusion that the
> design of asyn-ares.c is very limiting.
>
I ran into a similar problem when I was trying to bind to an interface, and
recently sent in some patches to address this problem.
https://github.com/bagder/curl/commit/6e4835c795996ee92ac1aa78733f23a089f310a5

What's the point of having all the goodies of the multi interface to
> use epoll etc, when waitperform function in asyn-ares.c just polls
> waiting for DNS queries to finish?
>

It only blocks when Curl_resolver_wait_resolv() is called and the code has
a clear warning that this function should be avoided. Are you doing http
transfers? ftp transfers? socks?

Curl_resolver_wait_resolv is still used in a few places:

connect.c: when trying to bind to an interface and the user supplied a
hostname. You can avoid that by supplying an interface name with the
if!xxx syntax.
ftp.c - looks like it should be removed, but might be difficult.
socks.c - ?
transfer.c - ?

 * Curl_resolver_wait_resolv()

 *

 * waits for a resolve to finish. This function should be avoided since
using
 * this risk getting the multi interface to "hang".

> I think the proper way would be to expose the resolving sockets up to
> the multi interface so the whole system is really asynchronous. Is
> there any reason why it wasn't done this way?
>
> Regards.
>
> Pedro.
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-12-18