Re: Regarding Async DNS resolver
Date: Tue, 16 Jul 2019 16:45:59 +0530
For the time being, I've already modified my application to poll for 100
msec instead of 1 second but this approach has two potential issues.
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)
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.
Since my application is already polling the connection fds, all the
read/write operations on connection sockets are event triggered.
IMO it would be better to wake up the thread only when DNS is resolved
rather than polling every 100 msec. Since there is no logic in the
application (as application is not aware that CURL connection state) to
poll until DNS is resolved, changing poll time from 1 second to 100 msec
would also unnecessary increase system load. Please provide your comments.
On Tue, Jul 16, 2019 at 4:24 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Mon, 15 Jul 2019, Amit via curl-library wrote:
> > I would like to seek your opinion/thoughts if it is good idea to re-use
> > existing callback to notify the client about DNS resolution ?.
> I don't think that sounds like a good idea, no.
> To me it sounds like you're looking to patch libcurl rather than to
> your own application logic. Can't you just fix your one-second wait to
> this problem?
> / daniel.haxx.se | Get the best commercial curl support there is - from
> | Private help, bug fixes, support, ports, new features
> | https://www.wolfssl.com/contact/
Received on 2019-07-16