curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Recovering from dropped connections with multi curl

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 24 Mar 2017 15:57:31 +0100 (CET)

On Wed, 15 Mar 2017, doa379 wrote:

> I'm still trying to work this out. I'm finding that the main function is
> still getting unnecessarily stuck in the main while (U) loop for my
> application. I would like the function to end whether or not data has been
> received. I don't wish for it to keep hanging around at all. I would
> appreciate any further suggestions.

I spotted I forgot to respond to this. Sorry for that.

> // start
> while (U)
> {
> curl_multi_perform(curl_handle, &U);

This is probably because you write some sort of pseudo example here, but just
in case: you don't do any select() or similar in your loop so it'll waste far
too much CPU.

> while ((msg = curl_multi_info_read(curl_handle, &Q)))
> {
> eh = msg->easy_handle;
> curl_easy_getinfo(eh, CURLINFO_RESPONSE_CODE, &http_response);
>
> if (msg->msg == CURLMSG_DONE &&
> (msg->data.result == CURLE_COULDNT_CONNECT ||
> msg->data.result == CURLE_OPERATION_TIMEDOUT ||
> msg->data.result == CURLE_COULDNT_RESOLVE_HOST ||
> http_response == 0 ||
> http_response == 200 ||
> http_response == 206));

Why do all these weirdo checks? When msg->msg == CURLMSG_DONE evaluates true,
that transfer is done. Complete. Over. You can check the return code etc to
decide how to deal with the transfer that just ended, but it is still over.

When the transfer is over, I would suggest you leave the loop if you only do
one transfer, or you remove the easy handle from the multi handle if you have
more than one going.

> while ((msg = curl_multi_info_read(curl_handle, &Q)))

You can't call this funtion again expecting to get the same data returned. It
drains the queue when you call it.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2017-03-24