Re: Curl timeout option in milliseconds
Date: Sat, 16 Nov 2019 16:53:43 +0530
Thanks for the clarification. Apologies for missing out to answer your
backend resolver query. Libcurl build is actually done by our application
product and I donot have the info with me.
Will check with them.
I did check your blog on libcurls-name-resolving and got some info about
the c-ares and threaded solutions for asynchronous name resolving.
Looking at curl docs, I learnt about the - - disable-ares option to disable
C-ARES support thereby reducing libcurl size. I can check with my product
team if this option was used in our libcurl build.
Kindly guide me if this would help. Also, if there is anyother way to
enable the async/threaded resolving, kindly let me know the same too.
Thanks and regards,
Karthikeyan T S.
On Fri, 15 Nov 2019, 19:24 Daniel Stenberg, <daniel_at_haxx.se> wrote:
> > Cases 1, 2 and 3 work fine but timeout occurs wrongly in cases 4 and 5.
> > Please correct me if my understanding here is wrong.
> Didn't this change the behavior? Your original statement said sub second
> timeouts still took a full second but in this output it looks like they
> You also never answered my question about what resolver backend your build
> using but I think that the above behavior answers it for me with enough
> I think libcurl returns an error for you due to this condition:
> ... this is because you've built libcurl to use the synchronous name
> and we can only time-out that with signal() and that function only has
> second resolution. If you ask for a shorter timeout, that can't be
> libcurl defaults to using the threaded resolver these days which will fire
> the resolver in a sepearate thread that can be abandonded easier and in
> than a second.
> / 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-11-16