Download
Browse source Changelog
Documentation
Project   Bug Bounty   Help us   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users Mailing lists Book: Everything curl Video presentations Report a bug Paid support
Development
Autobuilds Code Style Contribute Deprecate Internals Release Notes Release Procedure Roadmap Run Tests Security Process Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Regarding Async DNS resolver

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 16 Jul 2019 14:27:06 +0200 (CEST)

On Tue, 16 Jul 2019, Amit wrote:

> 1> During testing, I have seen that DNS is getting resolved in 40 msec but
> request is going out of the box only in the next poll iteration. Since there
> are other high priority tasks running in the system, sometime this 100 msec
> timer event is getting processed with delay which is adding additional 100 -
> 200 msec delay and impacting the UI (user interface) experience.

Right, and I don't actually advocate using 100ms all the time. It needs to be
shorter at first and then increase over time. curl_multi_timeout() return such
timeouts.

> 2. The another issue with 100 msec polling is that my application will keep
> on polling every 100 msec and the thread in which CURL is running at
> MEDIUM priority, this would create issue for other low priority threads.

Really? When curl ends up not doing anything because there's nothing to do
yet, it takes a fraction of a millisecond on most hardware. It seems unlikely
to have a measurable impact.

> IMO it would be better to wake up the thread only when DNS is resolved
> rather than polling every 100 msec.

Agreed, that is much better. But in this case it is rather difficult. The name
resolving is done in a separate thread and there's no signalling done when the
resolve phase is completed - exactly because it doesn't use any socket/file
descriptor internally. libcurl itself polls that information when the resolver
thread is used.

I think a DNS-completed callback from the resolver-thread would be a bad idea.

The *better* fix would be to instead use a pipe/sockpair to signal that the
name resolve is complete and then have the application be able to wait on
that. But that's problematic on Windows. 

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2019-07-16