Re: Regarding Async DNS resolver
Date: Mon, 22 Jul 2019 18:08:31 +0530
I have done the changes as per your suggestion - that is, to create socket
pair during async thread initialization, return the read socket fd to
client application and write dummy data to signal client that socket is
I did the testing on version which I am using (7.57.11) and verified the
Could you please review the attached patch file (generated after merging
the changes to latest libcurl) ? .
On Wed, Jul 17, 2019 at 5:14 AM Amit <itsamitkatyal_at_gmail.com> wrote:
> 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
>> >> 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
>> you need to do that yourself.
>> OK, will check if it is straightforward to back port the required
>> > 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
>> is ever called from another thread) and introduce the typical threading
>> 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
>> curl itself created), then surely those are not using the same thread
>> 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
>> >> that.
>> > Are you suggesting that let CURL internally create pipe/socket pair for
>> > 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
>> > the connection ?
>> > Regarding your concern on Windows, I am not sure about the CURL
>> > process, but since I am working on linux, would like to know if It if
>> > 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
>> users could then either just remain the current method or a Windows
>> 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
>> / 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/
- application/octet-stream attachment: dns.patch