On Sat, Dec 17, 2011 at 9:33 PM, Pedro Larroy <[email protected]>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
