Re: Regarding Async DNS resolver

On Wed, Jul 17, 2019 at 4:13 AM Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Tue, 16 Jul 2019, Amit wrote:
>
> >> 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.
> >
> > Thanks, will use curl_multi_timeout() instead of fixed 100 msec
> > timer.
>
> Just note that curl_multi_timeout() only started to return those suitable
> timeouts during the threaded name resolver in 7.60.0, so in earlier
> versions
> you need to do that yourself.
>
> OK, will check if it is straightforward to back port the required
changes.

> > why do you think notifying DNS-completed in resolver thread is a bad
> idea ?
>
> Because it would be surprising to applications (since no callbacks in
> libcurl
> is ever called from another thread) and introduce the typical threading
> issues
> requiring mutexes, locks etc and risk causing race conditions in the app.
>
>

> > Anyways, application would be handling that DNS-completed event in CURL
> > thread context.
>
> If you call libcurl from thread A and the callback comes from thread B
> (that
> curl itself created), then surely those are not using the same thread
> contexts?
>
> Yes, Callback will be called from another thread context (created by
cur) but client will simply post an event
     to curl thread in the callback so that synchronization is not
required. On receiving the event, curl thread will
     perform necessary action in its own context. This will ensure that
curl API's are only called in single thread context.
     Do you see any issues with above approach ? or your concern is that
you don't want to define/restrict the callback
     implementation behavior and would prefer the curl implementation to be
as per its existing design (which doesn't
     recommend calling callback in another thread context as I have seen
callback being called in the 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.
>
> > Are you suggesting that let CURL internally create pipe/socket pair for
> DNS
> > resolution and application wait on the same fd ?
>
> I'm suggesting that would be one way to offer a solution.
>
> > 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 ?
>
> Correct.
>
> > 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.
>
> Sure, a solution that only works for non-Windows is totally fine, as
> Windows
> users could then either just remain the current method or a Windows
> developer
> could work on providing the corresponding solution for that platform.
>
> As I am new to curl, It would be great if you can provide me some
pointer for similar kind of implementation already
     available in the curl, so that I can refer the same for this use-case.

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