The suggested fix works.
Now, the runtime interval is as expected, about 1000 ms.
On Mon, Mar 15, 2021 at 3:01 PM Daniel Stenberg wrote:
> On Sun, 14 Mar 2021, Daniel Stenberg via curl-library wrote:
>
> > I filed it as an issue for you: https://github.com/curl/curl/issues/6744
>
> It'd be very
On Sun, 14 Mar 2021, Daniel Stenberg via curl-library wrote:
I filed it as an issue for you: https://github.com/curl/curl/issues/6744
It'd be very interesting if you could try out my suggested fix and tell me how
it works. Filed as PR https://github.com/curl/curl/pull/6745
--
/ daniel.hax
On Fri, 12 Mar 2021, Andrei Bica wrote:
I've managed to produce this behavior by using a modified multi-poll.c
example (see https://pastebin.com/3iua80G8) which makes 10 HTTP requests to
"example.org:8200", set CURLOPT_TIMEOUT_MS to 1000 for each request and
CURLMOPT_MAX_TOTAL_CONNECTIONS to 1
I've managed to produce this behavior by using a modified multi-poll.c
example (see https://pastebin.com/3iua80G8) which makes 10 HTTP requests to
"example.org:8200", set CURLOPT_TIMEOUT_MS to 1000 for each request and
CURLMOPT_MAX_TOTAL_CONNECTIONS to 1 for the multi handle.
I've used iptables to
On Mon, 8 Mar 2021, Andrei Bica via curl-library wrote:
By using CURLOPT_TIMEOUT we can only set the transfer timeout, which doesn't
include the time it waits for the transfer to begin.
I believe this is wrong.
CURLOPT_TIMEOUT sets the maximum time allowed for the entire operation to use,
no
Trying to make multiple HTTP requests using multi interface
with CURLMOPT_MAX_TOTAL_CONNECTIONS set to 1 will result in the requests
being serialized, one at a time.
Is there a way (API feature) to limit how long the request will take,
including the time it waits in the internal queue of multi hand
