On Mon, 3 Oct 2011, Rich Gray wrote:

> "Before version 7.20.0: If you receive CURLM_CALL_MULTI_PERFORM, this
> basically means that you should call curl_multi_perform again, before you
> select() on more actions.

> I'm trying to figure out what this really means.

If you use a recent libcurl I think you should ignore the entire paragraph! It
is basically trying to describe how to act when CURLM_CALL_MULTI_PERFORM is
returned, and that return code is never used in modern libcurl versions.

> What about from 7.20.0 onward? The bolding of IMMEDIATELY makes it seem
> like one MUST (in the RFC sense) call 'perform if one gets
> CURLM_CALL_MULTI_PERFORM. Is this really so? I understand that it means
> 'perform has more work to do without going back to select(), but what if I
> have other things to do? What if I want to go back to the select() because
> I want to check for and process any new UDP traffic first? Is this harmful?
> Is this really more along the lines of an RFC MAY?

The return code means that libcurl has more work to do that is already known,
so that waiting for more actions on libcurl's sockets would be wrong as they
may not yet indicate that something needs to be done.

It was a confusing return code and a bad design choice to feature, which is
why we've since removed it from use.

> For program timing, my select() timevals are always a second or less. So, if
> I can guarantee that 'perform will be called at least once a second, do I
> need to even mess with getting the timeout value from libcurl?

No, then you'll be fine! Unless of course if you for some reason aim for
sub-second resolution on timouts set to libcurl, but I think you figured that
out already! =)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html