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
