On Tue, 23 Jul 2019, Amit wrote:
I have added the changes under compile time switch (HAVE_SOCKET) to fix
compilation on Windows.
I think you meant HAVE_SOCKETPAIR ?
But also, you reintroduced several of the code style fixes. I propose you run
'make checksrc' to have the build point out so
On Mon, Jul 22, 2019 at 10:27 PM Daniel Stenberg wrote:
> On Mon, 22 Jul 2019, Amit wrote:
>
> > 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
On Mon, 22 Jul 2019, Amit wrote:
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 readable.
I did the testing on version whic
Hi Daniel,
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
readable.
I did the testing on version which I am using (7.57.11) and
On Wed, Jul 17, 2019 at 4:13 AM Daniel Stenberg 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_mu
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_timeo
Ok, thanks for the clarification.
Please see below my reply inline.
On Tue, Jul 16, 2019 at 5:57 PM Daniel Stenberg 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 p
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
Hi Daniel,
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. Sinc
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 the
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 rat
Hi All,
This is regarding performance issue due to usage of async DNS resolver for
MULTI interface in lib CURL.
My application is using lib CURL (7.57 version) Muti interface with async
DNS resolver enabled (I.e CURLRES_ASYNCH and POSIX_THREADED are defined).
But I am facing performance issues as
11 matches
Mail list logo
