Re: Regarding Async DNS resolver

Ok, thanks for the clarification.

Please see below my reply inline.

On Tue, Jul 16, 2019 at 5:57 PM Daniel Stenberg <daniel_at_haxx.se> wrote:

> 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.
>

> [amitka] Thanks, will use curl_multi_timeout() instead of fixed 100 msec
> timer.

> > 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.
>

> [amitka:] Sorry for the confusion, the use-case I was referring to was
> when multiple requests are in progress (application does fires multiple
> parallel requests, to fetch the posters and other data) then it might
> end-up in introducing 100-200 msec delay in processing the queued request.
> BTW so far I haven't seen any impact during my testing but was concerned
> with approach of free running 100 msec timer.
>

> 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.

    [amitka] Small clarification, why do you think notifying DNS-completed
in resolver thread is a bad idea ?
    Anyways, application would be handling that DNS-completed event in CURL
thread context.

> 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.
>

> [amitka] Are you suggesting that let CURL internally create pipe/socket
> pair for DNS resolution and application wait on the

                 same fd ?
                 And on DNS resolution, CURL will write to the pipe, which
will cause application thread to wake up and application
                 can trigger the CURL to resume the connection ?.

                  Regarding your concern on Windows, I am not sure about
the CURL development process, but since I am
                  working on linux, would like to know if It if okay to
implement it only for linux ? If you are fine, then I can explore
                  more in this direction. Please suggest.

> --
>
> / 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