On Tue, Jul 6, 2010 at 1:16 PM, Brian Makin <makin_at_vivisimo.com> wrote:
> Thank you for the quick feedback. We've added the call to
> curl_multi_timeout, which seems to work *most* of the time.

What's the behavior of the program when it doesn't work?

> Unfortunately, when we did a very quick test [1], 8 out of 100 times the
> returned timeout from curl_multi_timeout was -1. According to the man

I need more info to understand what's happening here. Here is what I understand
Your ran a program 100x from the command line. I'm guessing that
program called curl_multi_timeout multiple times within some sort of
loop which included curl_multi_perform and and curl_multi_fdset. On 8
invocations of the program, in one of the iterations of the loop,
curl_multi_timeout returned -1. This caused the program not to work on
that invocation.

> curl_multi_fdset(curlm, ...);
> curl_multi_timeout(curlm, &suggested_timeout);
>
> timeout = external_timeout;
>

Move this code closer to the select:

> if (timeout > 1000) {
>    timeout = 1000;
> }
> if (suggested_timeout >= 0 &&
>    timeout > suggested_timeout)
> {
>    timeout = suggested_timeout;
> }
>
> select(..., timeout);

Are you converting timeout to a timeval correctly?

Other things that can come in handy when debugging are wireshark (you
can see where curl is pausing) and registering curl callbacks related
to logging - which can give you verbose information about where curl
is in its state machine at the time of the log message. See
CURLOPT_VERBOSE and CURLOPT_DEBUGFUNCTION, which you set on the easy
handle you add to the multi handle.

-Costa
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-07-06